From 4585ae9fb1991ebe8807cb5403b20b461118d14a Mon Sep 17 00:00:00 2001 From: "Stig S. Bakken" Date: Sat, 8 Sep 2001 08:55:42 +0000 Subject: [PATCH] wrapped to 80 columns :) --- Zend/RFCs/001.txt | 131 ++++++++++++++++++++++++++++------------------ 1 file changed, 80 insertions(+), 51 deletions(-) diff --git a/Zend/RFCs/001.txt b/Zend/RFCs/001.txt index 11863d2cd9..bf1d847b97 100644 --- a/Zend/RFCs/001.txt +++ b/Zend/RFCs/001.txt @@ -4,40 +4,52 @@ 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). +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. +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. +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(); +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. +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: @@ -65,43 +77,60 @@ Consider the following code: 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. +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. +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). +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. +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. -- 2.40.0