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.
If You Enjoyed This Post Please Take a Second To Share It.
You Might Also Like
Stay Connected With Free Updates
 |
 |
 |
|
Subscribe via Email
|
