diff options
Diffstat (limited to 'Zend/RFCs')
| -rw-r--r-- | Zend/RFCs/001.txt | 136 | ||||
| -rw-r--r-- | Zend/RFCs/002.txt | 169 | ||||
| -rw-r--r-- | Zend/RFCs/003.txt | 72 |
3 files changed, 0 insertions, 377 deletions
diff --git a/Zend/RFCs/001.txt b/Zend/RFCs/001.txt deleted file mode 100644 index bf1d847b97..0000000000 --- a/Zend/RFCs/001.txt +++ /dev/null @@ -1,136 +0,0 @@ -Revamped object model using object handles -=========================================== - -Background ----------- - -In the Zend Engine 1.0 (and its predecessor the PHP 3 scripting -engine) the object model's design is that instantiated objects are -language values. This means that when programmers are performing -operations, such variable assignment and passing parameters to -functions, objects are handled very similarly to the way other -primitive types are handled such as integers and strings. -Semantically this means that the whole object is being copied. The -approach Java takes is different where one refers to objects by handle -and not by value (one can think of a handle as an objects' ID). - -Need ----- - -Unfortunately, the approach taken up to now has severely limited the -Zend Engine's object oriented model, both feature and simplicity -wise. One of the main problems with the former approach is that object -instantiation and duplication is very hard to control, a problem which -can not only lead to inefficient development but also often to strange -run-time behavior. Changing the object model to a handle oriented -model will allow the addressing of many needs such as destructors, -de-referencing method return values, tight control of object -duplication and more. - -Overview --------- - -The proposed object model is very much influenced by the Java -model. In general, when you create a new object you will be getting a -handle to the object instead of the object itself. When this handle is -sent to functions, assigned and copied it is only the handle which is -copied/sent/assigned. The object itself is never copied nor -duplicated. This results in all handles of this object to always point -at the same object making it a very consistent solution and saving -unnecessary duplication and confusing behavior. - -Functionality -------------- - -After this change the basic use of objects will be almost identical to -previous versions of the scripting engine. However, you won't bump -into awkward and confusing copying & destructing of objects. In order -to create and use a new object instance you will do the following: -$object = new MyClass(); $object->method(); - -The previous code will assign $object the handle of a new instance of -the class MyClass and call one of its methods. - - -Consider the following code: - -1 class MyClass -2 { -3 function setMember($value) -4 { -5 $this->member = $value; -6 } -7 -8 function getMember() -9 { -10 return $this->member; -11 } -12 } -13 -14 function foo($obj) -15 { -16 $obj->setMember("foo"); -17 } -18 -19 $object = new MyClass(); -20 $object->setMember("bar"); -21 foo($object); -22 print $object->getMember(); - -Without the new Java-like handles, at line 20 the objects' data member -member is set to the string value of "bar". Because of the internal -representation of objects in the Zend Engine 1.0, the object is marked -as a reference, and when it is sent by value to the function foo, it -is duplicated (!). Therefore, the call to foo() on line 21 will -result in the $obj->setMember("foo") call being called on a duplicate -of $object. Line 22 will then result in "bar" being printed. - -This is how the scripting engine has worked until today. Most -developers are probably unaware of the fact that they aren't always -talking to the same object but often duplicates; others may have -realized this can usually be solved by always passing objects by -reference (unless a replica is actually desired, which is uncommon). - -The new object model will allow for a much more intuitive -implementation of the code. On line 21, the object's handle (ID) is -passed to foo() by value. Inside foo(), the object is fetched -according to this handle and, therefore, the setMember() method is -called on the originally instantiated object and not a copy. Line 22 -will therefore result in "foo" being printed. This approach gives -developers tighter control of when objects are created and duplicated. -An additional not-as-important benefit is that the object handle will -be passed to foo() by value, which most probably will also save -unnecessary duplication of the value containing the ID itself and thus -additionally improving run-time performance. - -This was just a simple description of why the new object model solves -awkward behavior and makes object handling much easier, intuitive and -efficient. The importance of this change goes far beyond what is -mentioned in this section as you will see in further sections which -describe new features with a majority of them being based on this -change. - -Compatibility Notes --------------------- - -Many PHP programmers aren't even aware of the copying quirks of the -current object model and, therefore, there is a relatively good chance -that the amount of PHP applications that will work out of the box or -after a very small amount of modifications would be high. - -To simplify migration, version 2.0 will support an optional -'auto-clone' feature, which will perform a cloning of the object -whenever it would have been copied in version 1.0. Optionally, it -will also be possible to request that the engine will emit an E_NOTICE -message whenever such an automatic clone occurs, in order to allow -developers to gradually migrate to the version 2.0-style behavior -(without automatic clones). - -Dependencies ------------- - -The new object model is not dependent on other features. Many of the -other Zend Engine 2.0 features, such as the $foo->bar()->barbara() -syntax, destructors and others completely rely on this new object -model. - diff --git a/Zend/RFCs/002.txt b/Zend/RFCs/002.txt deleted file mode 100644 index 263c4116c9..0000000000 --- a/Zend/RFCs/002.txt +++ /dev/null @@ -1,169 +0,0 @@ -Title: Zend 2.0 Namespaces -Version: $Revision$ -Status: draft -Maintainer: Stig S. Bakken <ssb@fast.no> -Created: 2001-09-08 -Modified: 2001-09-08 - - -1. Background/Need -================== - -PHP and Zend 1.0 have come to a point where a lot of reusable code is -being written; from simple functions and classes to entire application -frameworks. It is becoming increasingly difficult to avoid symbol -name collisions with the current scoping methods. - -The symbol scopes available in Zend 1.0 are the global scope, the -class scope and the function scope. All scopes but classes may -contain variables, only the class and global scopes may contain -functions, while only the global scope may contain constants and -classes. This means that all of Zend 1.0's scoping methods are -inherently limited for solving symbol name collision problems. - - -2. Overview -=========== - -Namespaces in Zend 2.0 provide a way to manage the symbol collision -problem by making it possible to define multiple symbol tables able to -contain all types of symbols. Zend will get the notion of a current -namespace, defaulting to the current global one. The current name -space may be changed on a file-by-file basis. Symbols in other name -spaces than the current one may be referenced using a new namespace -operator. It will be possible to "import" symbols from one namespace -into another. - - -3. Functionality -================ - -3.1. Namespace Syntax -===================== - -The namespace operator ":" is used to refer to symbols in other -namespaces than the current one: - -Class: Namespace:class -Function: Namespace:function -Static method: Namespace:class::method -Variable: $Namespace:variable -Constant: Namespace:CONSTANT -Class variable: $Namespace:class::variable - -To refer to symbols in the global namespace, symbols are prefixed with -only the namespace operator: - -Class: :class -Function: :function -Static method: :class::method -Variable: $:variable -Constant: :CONSTANT -Class variable: $:class::variable - -Note: $:variable will effectively be just another syntax for -$GLOBALS['variable']. - -A namespace may have a name containing a ":", it is always the last -":" character in the symbol qualifier that is the actual namespace -operator: - -Class: Name:Space:class -Function: Name:Space:function -Static method: Name:Space:class::method -Variable: $Name:Space:variable -Constant: Name:Space:CONSTANT -Class variable: $Name:Space:class::variable - -(Here, the ":" between "Name" and "Space" is part of the name, it is -the one after "Space" that is the namespace operator.) - - -3.2. Defining Namespaces -======================== - -Individual files may define a namespace that will apply to the entire -file. If no "namespace" operator occurs in the file, it will be in -the global namespace: - - 1 namespace HTML; - 2 - 3 class Form { - 4 function Form() { - 5 // constructor - 6 } - 7 // ... - 8 } - -Or with the "nested" name syntax: - - 1 namespace HTML:Form; - 2 - 3 class Image { - 4 var $src; - 5 function Image($src) { - 6 $this->src = $src; - 7 } - 8 // ... - 9 } - -Code executed within the "HTML" namespace may refer to the Form class -as just "Form". Code executed from within other namespaces has to -refer to it as "HTML:Form". The "namespace" statement must occur -before any other statements in the file. - -# [ssb 2001-09-08]: -# Should it be possible to "add" symbols to a namespace by including a -# second file with the same namespace statement? - - -3.3. Importing Symbols -====================== - -It is possible to import symbols from another namespace into the -current one with the "import" statement: - - import * from HTML; // all symbols - - import Form from HTML; // single symbols - - import Form,Table from HTML; // multiple symbols - -There is a potential for name clashes between symols of different -types that have the same qualifier syntax. These are resolved in this -order: class, function, constant. - -Optionally, the symbol type may be explicitly given to import (as -"class", "function", "variable" or "constant"): - - import class Form from HTML; - -And finally, you may import all symbols of a given type: - - import constant * from HTML:Table; - -The namespace with its symbols must already be defined before using -"import". - - -4. Compatibility Notes -====================== - -Old code that does not take advantage of namespaces will run without -modifications. - - -5. Dependencies -=============== - -The class variable syntax depends on this class variables being -implemented in the new ZE2 object model. - - -6. Acknowledgements -=================== - -Andi Gutmans <andi@zend.com> and Zeev Suraski <zeev@zend.com> for -initial ZE2 namespaces proposal - -Dean Hall <php@apt7.com> for the initial symbol qualification syntax diff --git a/Zend/RFCs/003.txt b/Zend/RFCs/003.txt deleted file mode 100644 index aa90691b19..0000000000 --- a/Zend/RFCs/003.txt +++ /dev/null @@ -1,72 +0,0 @@ -Title: Loose type requirements for functions -Version: $Revision$ -Status: draft -Maintainer: Brian Moon <brianm@dealnews.com> -Created: 2001-09-17 -Modified: 2001-09-17 - - -1. Background/Need -================== - -Many internal function of PHP will reject parameters because of their -type (the array and variable function come to mind). For userland -this is not an easy task as there is no uniform way to do it. An -addition to the engine for requiring loose types would allow -delevopers to know that the data passed to their functions is of the -correct type and reduce the need for duplicating the same code in -every function to check for the type of data. - - -2. Overview -=========== - -Loose typing mostly means evaluating the contents of the variable and -not the type of the variable itself. The requirements for this would -and should work much like several of the is_* functions do now. - -The typing of parameters would be optional and those not typed would -simply continue to be treated as they are now. - -3. Functionality -================ - -3.1. Allowed Types -================== - -Only loose types should be needed to ensure the data is usable by the -function. Duplicating the functionallity of is_scalar, is_resource, -is_array and is_object should give developers all the information they -need to use a variable correctly. - -3.2. Syntax -=========== - -The current function syntax should be expanded to allow typing of -variables inline in a C style. - -function foo ($var){ -} - -could be changed to require an array such as: - -function foo (array $var){ -} - -3.3. Errors -=========== - -Mis-matches in type should be reported as fatal errors and should halt -the execution of a script as that function can not be run and code -following could not reliably run. - - -4. Compatibility Notes -====================== - -Old code that does not take advantage of this will run without -modifications. - - - - |