Return to 001.txt CVS log

Up to [ELWIX - Embedded LightWeight unIX -] / embedaddon / php / Zend / RFCs

Annotation of embedaddon/php/Zend/RFCs/001.txt, revision 1.1.1.1

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