Return to 001.txt CVS log

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

php

    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: