1Revamped object model using object handles 2=========================================== 3 4Background 5---------- 6 7In the Zend Engine 1.0 (and its predecessor the PHP 3 scripting 8engine) the object model's design is that instantiated objects are 9language values. This means that when programmers are performing 10operations, such variable assignment and passing parameters to 11functions, objects are handled very similarly to the way other 12primitive types are handled such as integers and strings. 13Semantically this means that the whole object is being copied. The 14approach Java takes is different where one refers to objects by handle 15and not by value (one can think of a handle as an objects' ID). 16 17Need 18---- 19 20Unfortunately, the approach taken up to now has severely limited the 21Zend Engine's object oriented model, both feature and simplicity 22wise. One of the main problems with the former approach is that object 23instantiation and duplication is very hard to control, a problem which 24can not only lead to inefficient development but also often to strange 25run-time behavior. Changing the object model to a handle oriented 26model will allow the addressing of many needs such as destructors, 27de-referencing method return values, tight control of object 28duplication and more. 29 30Overview 31-------- 32 33The proposed object model is very much influenced by the Java 34model. In general, when you create a new object you will be getting a 35handle to the object instead of the object itself. When this handle is 36sent to functions, assigned and copied it is only the handle which is 37copied/sent/assigned. The object itself is never copied nor 38duplicated. This results in all handles of this object to always point 39at the same object making it a very consistent solution and saving 40unnecessary duplication and confusing behavior. 41 42Functionality 43------------- 44 45After this change the basic use of objects will be almost identical to 46previous versions of the scripting engine. However, you won't bump 47into awkward and confusing copying & destructing of objects. In order 48to create and use a new object instance you will do the following: 49$object = new MyClass(); $object->method(); 50 51The previous code will assign $object the handle of a new instance of 52the class MyClass and call one of its methods. 53 54 55Consider the following code: 56 571 class MyClass 582 { 593 function setMember($value) 604 { 615 $this->member = $value; 626 } 637 648 function getMember() 659 { 6610 return $this->member; 6711 } 6812 } 6913 7014 function foo($obj) 7115 { 7216 $obj->setMember("foo"); 7317 } 7418 7519 $object = new MyClass(); 7620 $object->setMember("bar"); 7721 foo($object); 7822 print $object->getMember(); 79 80Without the new Java-like handles, at line 20 the objects' data member 81member is set to the string value of "bar". Because of the internal 82representation of objects in the Zend Engine 1.0, the object is marked 83as a reference, and when it is sent by value to the function foo, it 84is duplicated (!). Therefore, the call to foo() on line 21 will 85result in the $obj->setMember("foo") call being called on a duplicate 86of $object. Line 22 will then result in "bar" being printed. 87 88This is how the scripting engine has worked until today. Most 89developers are probably unaware of the fact that they aren't always 90talking to the same object but often duplicates; others may have 91realized this can usually be solved by always passing objects by 92reference (unless a replica is actually desired, which is uncommon). 93 94The new object model will allow for a much more intuitive 95implementation of the code. On line 21, the object's handle (ID) is 96passed to foo() by value. Inside foo(), the object is fetched 97according to this handle and, therefore, the setMember() method is 98called on the originally instantiated object and not a copy. Line 22 99will therefore result in "foo" being printed. This approach gives 100developers tighter control of when objects are created and duplicated. 101An additional not-as-important benefit is that the object handle will 102be passed to foo() by value, which most probably will also save 103unnecessary duplication of the value containing the ID itself and thus 104additionally improving run-time performance. 105 106This was just a simple description of why the new object model solves 107awkward behavior and makes object handling much easier, intuitive and 108efficient. The importance of this change goes far beyond what is 109mentioned in this section as you will see in further sections which 110describe new features with a majority of them being based on this 111change. 112 113Compatibility Notes 114-------------------- 115 116Many PHP programmers aren't even aware of the copying quirks of the 117current object model and, therefore, there is a relatively good chance 118that the amount of PHP applications that will work out of the box or 119after a very small amount of modifications would be high. 120 121To simplify migration, version 2.0 will support an optional 122'auto-clone' feature, which will perform a cloning of the object 123whenever it would have been copied in version 1.0. Optionally, it 124will also be possible to request that the engine will emit an E_NOTICE 125message whenever such an automatic clone occurs, in order to allow 126developers to gradually migrate to the version 2.0-style behavior 127(without automatic clones). 128 129Dependencies 130------------ 131 132The new object model is not dependent on other features. Many of the 133other Zend Engine 2.0 features, such as the $foo->bar()->barbara() 134syntax, destructors and others completely rely on this new object 135model. 136 137
