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:
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.
projects / php / commitdiff