From: Andi Gutmans Date: Mon, 27 Aug 2001 18:43:20 +0000 (+0000) Subject: - Add sample RFC X-Git-Tag: PRE_SUBST_Z_MACROS~338 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=0378e545a00cd6e35e72f9ae8af57b2cad288353;p=php - Add sample RFC --- diff --git a/Zend/RFCs/001.txt b/Zend/RFCs/001.txt new file mode 100644 index 0000000000..11863d2cd9 --- /dev/null +++ b/Zend/RFCs/001.txt @@ -0,0 +1,107 @@ +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. +