mirror of
https://github.com/php/php-src.git
synced 2024-11-24 18:34:21 +08:00
137 lines
5.4 KiB
Plaintext
137 lines
5.4 KiB
Plaintext
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.
|
|
|