mirror of
https://github.com/php/php-src.git
synced 2024-09-22 02:17:32 +00:00
742 lines
24 KiB
Plaintext
742 lines
24 KiB
Plaintext
Changes in the Zend Engine 2.0
|
|
|
|
* New Object Model.
|
|
|
|
The Zend Engine's handling of objects has been completely
|
|
changed in order to allow for new features, but also to increase
|
|
its performance.
|
|
|
|
Objects were handled in previous versions like primitive types
|
|
(for instance integers and strings). The drawback of this method
|
|
is, that semantically the whole object was copied when a
|
|
variable was assigned or parameters were passed to a method. The
|
|
new approach refers to objects by handle and not by value (one
|
|
can think of a handle as an object's ID).
|
|
|
|
Many PHP programmers aren't even aware of the copying quirks of
|
|
the old 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.
|
|
|
|
* Private and Protected Members.
|
|
|
|
The Zend Engine 2.0 introduces private and protected member variables.
|
|
Note that for performance reasons no error message is emitted in
|
|
case of an illegal access to a private or protectecd member variable.
|
|
|
|
Example:
|
|
|
|
<?php
|
|
class MyClass {
|
|
private $Hello = "Hello, World!\n";
|
|
protected $Bar = "Hello, Foo!\n";
|
|
protected $Foo = "Hello, Bar!\n";
|
|
|
|
function printHello() {
|
|
print "MyClass::printHello() ".$this->Hello;
|
|
print "MyClass::printHello() ".$this->Bar;
|
|
print "MyClass::printHello() ".$this->Foo;
|
|
}
|
|
}
|
|
|
|
class MyClass2 extends MyClass {
|
|
protected $Foo;
|
|
|
|
function printHello() {
|
|
MyClass::printHello(); /* Should print */
|
|
print "MyClass2::printHello() ".$this->Hello; /* Shouldn't print out anything */
|
|
print "MyClass2::printHello() ".$this->Bar; /* Shouldn't print (not declared)*/
|
|
print "MyClass2::printHello() ".$this->Foo; /* Should print */
|
|
}
|
|
}
|
|
|
|
$obj = new MyClass();
|
|
print $obj->Hello; /* Shouldn't print out anything */
|
|
print $obj->Bar; /* Shouldn't print out anything */
|
|
print $obj->Foo; /* Shouldn't print out anything */
|
|
$obj->printHello(); /* Should print */
|
|
|
|
$obj = new MyClass2();
|
|
print $obj->Hello; /* Shouldn't print out anything */
|
|
print $obj->Bar; /* Shouldn't print out anything */
|
|
print $obj->Foo; /* Shouldn't print out anything */
|
|
$obj->printHello();
|
|
?>
|
|
|
|
Protected member variables can be accessed in classes extending the class
|
|
they are declared in, whereas private member variables can only be accessed
|
|
by the class they belong to.
|
|
|
|
Note: Protected member variables have to be declared in every class they
|
|
are used!
|
|
|
|
* Object Cloning.
|
|
|
|
The Zend Engine 1.0 offered no way a user could decide what copy
|
|
constructor to run when an object is duplicated. During
|
|
duplication, the Zend Engine 1.0 did a bitwise copy making an
|
|
identical replica of all the object's properties.
|
|
|
|
Creating a copy of an object with fully replicated properties is
|
|
not always the wanted behavior. A good example of the need for
|
|
copy constructors, is if you have an object which represents a
|
|
GTK window and the object holds the resource of this GTK window,
|
|
when you create a duplicate you might want to create a new
|
|
window with the same properties and have the new object hold the
|
|
resource of the new window. Another example is if your object
|
|
holds a reference to another object which it uses and when you
|
|
replicate the parent object you want to create a new instance of
|
|
this other object so that the replica has its own separate copy.
|
|
|
|
An object copy is created by calling the object's __clone()
|
|
method.
|
|
|
|
Example:
|
|
|
|
<?php
|
|
$copy_of_object = $object->__clone();
|
|
?>
|
|
|
|
When the developer asks to create a new copy of an object, the
|
|
Zend Engine will check if a __clone() method has been defined or
|
|
not. If not, it will call a default __clone() which will copy
|
|
all of the object's properties. If a __clone() method is
|
|
defined, then it will be responsible to set the necessary
|
|
properties in the created object. For convenience, the engine
|
|
will supply a function that imports all of the properties from
|
|
the source object, so that they can start with a by-value
|
|
replica of the source object, and only override properties that
|
|
need to be changed. [The function hasn't been implemented yet]
|
|
|
|
Example:
|
|
|
|
<?php
|
|
class MyCloneable {
|
|
static $id = 0;
|
|
|
|
function MyCloneable() {
|
|
$this->id = self::$id++;
|
|
}
|
|
|
|
function __clone() {
|
|
$this->name = $clone->name;
|
|
$this->address = 'New York';
|
|
$this->id = self::$id++;
|
|
}
|
|
}
|
|
|
|
$obj = new MyCloneable();
|
|
|
|
$obj->name = 'Hello';
|
|
$obj->address = 'Tel-Aviv';
|
|
|
|
print $obj->id . "\n";
|
|
|
|
$obj = $obj->__clone();
|
|
|
|
print $obj->id . "\n";
|
|
print $obj->name . "\n";
|
|
print $obj->address . "\n";
|
|
?>
|
|
|
|
* Nested classes (namespaces).
|
|
|
|
The Zend Engine 1.0 provided only three scopes: the global
|
|
scope, the class scope and the function scope. All scopes but
|
|
classes could contain variables, only the class and global
|
|
scopes could contain functions, while only the global scope
|
|
could contain constants and classes. This means that all of the
|
|
Zend Engine 1.0's scoping methods were inherently limited for
|
|
solving symbol name collision problems.
|
|
|
|
The Zend Engine 2.0 introduces the concept of nested classes
|
|
to solve the symbol collision problem by making it possible to
|
|
define multiple symbol tables able to contain all types of
|
|
symbols. The Zend Engine is aware of a current class,
|
|
defaulting to the global scope. Each class can contain it's
|
|
own set of constants, functions and static variables. In order
|
|
to access a class's local symbols you can use the self:: class
|
|
accessor, for example, you can do self::$my_static_name = "Hello".
|
|
You can also use the class's name such as
|
|
MyClass::$my_static_name = "Hello". WIth both constants and
|
|
functions, if you don't specify a class context the current class
|
|
will be searched first and if the search fails then the global
|
|
scope will be searched. If you want to force PHP to only check the
|
|
global scope you can use the main:: accessor. For example,
|
|
main::strlen() to make sure you're calling the strlen() in the main
|
|
scope. You will only need to worry about this if you are defining
|
|
methods which have the same name as global functions. For
|
|
constants you can use the same notation such as self::MY_CONSTANT
|
|
or main::MY_CONSTANT.
|
|
Sometimes you will not want to access constants, functions or classes
|
|
via the class accessor (i.e. MyClass::) because you use them very
|
|
often and are an extremely slow typist. In this case, you can import
|
|
functions, classes and constants from classes with the import keyword.
|
|
It's quite self explanatory and there are a few examples below.
|
|
|
|
|
|
* Classes may contain classes.
|
|
|
|
Example:
|
|
|
|
<?php
|
|
class DB::MySQL {
|
|
var $host = '';
|
|
|
|
function db_connect($user) {
|
|
print "Connecting to MySQL database '$this->host' as $user\n";
|
|
}
|
|
}
|
|
|
|
class DB::Oracle {
|
|
var $host = 'localhost';
|
|
|
|
function db_connect($user) {
|
|
print "Connecting to Oracle database '$this->host' as $user\n";
|
|
}
|
|
}
|
|
|
|
$MySQL_obj = new DB::MySQL();
|
|
$MySQL_obj->db_connect('Susan');
|
|
|
|
$Oracle_obj = new DB::Oracle();
|
|
$Oracle_obj->db_connect('Barbara');
|
|
?>
|
|
|
|
* Classes may contain constants.
|
|
|
|
Example:
|
|
|
|
<?php
|
|
class foo {
|
|
const hey = 'hello';
|
|
}
|
|
|
|
print foo::hey;
|
|
?>
|
|
|
|
* Current namespace's symbol tables are searched first for
|
|
constants and functions.
|
|
|
|
Example:
|
|
|
|
The following code prints "foobar", not "foo", because
|
|
the class constant overrides the "global" constant of
|
|
the same name.
|
|
|
|
<?php
|
|
define('foo', 'bar');
|
|
|
|
class FooClass {
|
|
const foo = 'foobar';
|
|
|
|
function printFoo() {
|
|
print foo;
|
|
}
|
|
}
|
|
?>
|
|
|
|
* In the scope of a function, the current namespace is that
|
|
of the containing class/namespace.
|
|
|
|
Example:
|
|
|
|
<?php
|
|
class FooClass {
|
|
function foo() {
|
|
$this->bar();
|
|
bar();
|
|
}
|
|
|
|
function bar() {
|
|
print "foobar\n";
|
|
}
|
|
}
|
|
|
|
$obj = new FooClass;
|
|
$obj->foo();
|
|
$obj->foo();
|
|
?>
|
|
|
|
This prints "foobar" two times, since a bar() method exists
|
|
in the current namespace.
|
|
|
|
* It is possible to "import" symbols from one namespace into
|
|
another.
|
|
|
|
Example:
|
|
|
|
<?php
|
|
class MyClass {
|
|
class MyClass2 {
|
|
function hello() {
|
|
print "Hello, World in MyClass2\n";
|
|
}
|
|
}
|
|
|
|
function hello() {
|
|
print "Hello, World\n";
|
|
}
|
|
}
|
|
|
|
import function hello, class MyClass2 from MyClass;
|
|
|
|
MyClass2::hello();
|
|
hello();
|
|
?>
|
|
|
|
Example:
|
|
|
|
<?php
|
|
class MyOuterClass {
|
|
class MyInnerClass {
|
|
function func1() {
|
|
print "func1()\n";
|
|
}
|
|
|
|
function func2() {
|
|
print "func2()\n";
|
|
}
|
|
}
|
|
}
|
|
|
|
import class * from MyOuterClass;
|
|
import function func2 from MyOuterClass::MyInnerClass;
|
|
|
|
MyInnerClass::func1();
|
|
func2();
|
|
?>
|
|
|
|
Example:
|
|
|
|
<?php
|
|
class MyOuterClass {
|
|
const Hello = "Hello, World\n";
|
|
}
|
|
|
|
import const Hello from MyOuterClass;
|
|
print Hello;
|
|
?>
|
|
|
|
Old code that does not take advantage of namespaces will run
|
|
without modifications.
|
|
|
|
* Unified Constructors.
|
|
|
|
The Zend Engine allows developers to declare constructor methods
|
|
for classes. Classes which have a constructor method call this
|
|
method on each newly-created object, so it is suitable for any
|
|
initialization that the object may need before it can be used.
|
|
|
|
With the Zend Engine 1.0, constructor methods were class methods
|
|
that had the same name as the class itself. Since it is very
|
|
common to call parent constructors from derived classes, the way
|
|
the Zend Engine 1.0 worked made it a bit cumbersome to move
|
|
classes around in a large class hierarchy. If a class is moved
|
|
to reside under a different parent, the constructor name of that
|
|
parent changes as well, and the code in the derived class that
|
|
calls the parent constructor has to be modified.
|
|
|
|
The Zend Engine 2.0 introduces a standard way of declaring
|
|
constructor methods by calling them by the name __construct().
|
|
|
|
Example:
|
|
|
|
<?php
|
|
class BaseClass {
|
|
function __construct() {
|
|
print "In BaseClass constructor\n";
|
|
}
|
|
}
|
|
|
|
class SubClass extends BaseClass {
|
|
function __construct() {
|
|
parent::__construct();
|
|
print "In SubClass constructor\n";
|
|
}
|
|
}
|
|
|
|
$obj = new BaseClass();
|
|
$obj = new SubClass();
|
|
?>
|
|
|
|
For backwards compatibility, if the Zend Engine 2.0 cannot find
|
|
a __construct() function for a given class, it will search for
|
|
the old-style constructor function, by the name of the class.
|
|
Effectively, it means that the only case that would have
|
|
compatibility issues is if the class had a method named
|
|
__construct() which was used for different semantics.
|
|
|
|
* Destructors.
|
|
|
|
Having the ability to define destructors for objects can be very
|
|
useful. Destructors can log messages for debugging, close
|
|
database connections and do other clean-up work.
|
|
|
|
No mechanism for object destructors existed in the Zend Engine
|
|
1.0, although PHP had already support for registering functions
|
|
which should be run on request shutdown.
|
|
|
|
The Zend Engine 2.0 introduces a destructor concept similar to
|
|
that of other object-oriented languages, such as Java: When the
|
|
last reference to an object is destroyed the object's
|
|
destructor, which is a class method name __destruct() that
|
|
recieves no parameters, is called before the object is freed
|
|
from memory.
|
|
|
|
Example:
|
|
|
|
<?php
|
|
class MyDestructableClass {
|
|
function __construct() {
|
|
print "In constructor\n";
|
|
$this->name = 'MyDestructableClass';
|
|
}
|
|
|
|
function __destruct() {
|
|
print 'Destroying ' . $this->name . "\n";
|
|
}
|
|
}
|
|
|
|
$obj = new MyDestructableClass();
|
|
?>
|
|
|
|
Like constructors, parent destructors will not be called
|
|
implicitly by the engine. In order to run a parent destructor,
|
|
one would have to explicitly call parent::__destruct() in the
|
|
destructor body.
|
|
|
|
* Exceptions.
|
|
|
|
The Zend Engine 1.0 had no exception handling. The Zend Engine 2.0
|
|
introduces a exception model similar to that of other programming
|
|
languages.
|
|
|
|
Example:
|
|
|
|
<?php
|
|
class MyException {
|
|
function __construct($exception) {
|
|
$this->exception = $exception;
|
|
}
|
|
|
|
function Display() {
|
|
print "MyException: $this->exception\n";
|
|
}
|
|
}
|
|
|
|
class MyExceptionFoo extends MyException {
|
|
function __construct($exception) {
|
|
$this->exception = $exception;
|
|
}
|
|
|
|
function Display() {
|
|
print "MyException: $this->exception\n";
|
|
}
|
|
}
|
|
|
|
try {
|
|
throw new MyExceptionFoo('Hello');
|
|
}
|
|
|
|
catch (MyException $exception) {
|
|
$exception->Display();
|
|
}
|
|
?>
|
|
|
|
Old code that has no user-defined functions 'catch', 'throw' and
|
|
'try' will run without modifications.
|
|
|
|
* Dereferencing objects returned from functions.
|
|
|
|
Example:
|
|
|
|
<?php
|
|
class Circle {
|
|
function draw() {
|
|
print "Circle\n";
|
|
}
|
|
}
|
|
|
|
class Square {
|
|
function draw() {
|
|
print "Square\n";
|
|
}
|
|
}
|
|
|
|
function ShapeFactoryMethod($shape) {
|
|
switch ($shape) {
|
|
case 'Circle': return new Circle();
|
|
case 'Square': return new Square();
|
|
}
|
|
}
|
|
|
|
ShapeFactoryMethod('Circle')->draw();
|
|
ShapeFactoryMethod('Square')->draw();
|
|
?>
|
|
|
|
* Static member variables of static classes can now be
|
|
initialized.
|
|
|
|
Example:
|
|
|
|
<?php
|
|
class foo {
|
|
static $my_static = 5;
|
|
}
|
|
|
|
print foo::$my_static;
|
|
?>
|
|
|
|
* Parameters that are passed by reference to a function
|
|
may now have default values.
|
|
|
|
Example:
|
|
|
|
<?php
|
|
function my_function(&$var = null) {
|
|
if ($var === null) {
|
|
die('$var needs to have a value');
|
|
}
|
|
}
|
|
?>
|
|
|
|
* Built-In Backtracing.
|
|
|
|
Example:
|
|
|
|
<?php
|
|
$backtrace = debug_backtrace();
|
|
|
|
foreach ($backtrace as $step) {
|
|
if (!empty($step['args'])) {
|
|
foreach ($step['args'] as $arg) {
|
|
$args = isset($args) ? $args . ', ' : '';
|
|
$args .= var_export($arg, true);
|
|
}
|
|
} else {
|
|
$args = '';
|
|
}
|
|
|
|
$args = str_replace(array("\n", ',)'), array('', ')'), $args);
|
|
|
|
printf(
|
|
"%s%s(%s) [%s:%s]\n",
|
|
isset($step['class']) ? $step['class'] . '::' : '',
|
|
$step['function'],
|
|
$args,
|
|
$step['file'],
|
|
$step['line']
|
|
);
|
|
}
|
|
?>
|
|
|
|
* __autoload(). TBD.
|
|
|
|
* Method calls and property accesses can be overloaded
|
|
by class methods __call(), __get() and __set().
|
|
|
|
__get() and __set() Example:
|
|
|
|
<?php
|
|
class Setter {
|
|
public $n;
|
|
public $x = array('a' => 1, 'b' => 2, 'c' => 3);
|
|
|
|
function __get($nm) {
|
|
print "Getting [$nm]\n";
|
|
|
|
if(isset($this->x[$nm])) {
|
|
$r = $this->x[$nm];
|
|
print "Returning: $r\n";
|
|
return $r;
|
|
} else {
|
|
print "Nothing!\n";
|
|
}
|
|
}
|
|
|
|
function __set($nm, $val) {
|
|
print "Setting [$nm] to $val\n";
|
|
|
|
if(isset($this->x[$nm])) {
|
|
$this->x[$nm] = $val;
|
|
print "OK!\n";
|
|
} else {
|
|
print "Not OK!\n";
|
|
}
|
|
}
|
|
}
|
|
|
|
$foo = new Setter();
|
|
$foo->n = 1;
|
|
$foo->a = 100;
|
|
$foo->a++;
|
|
$foo->z++;
|
|
var_dump($foo);
|
|
?>
|
|
|
|
__call() Example:
|
|
|
|
<?php
|
|
class Caller {
|
|
var $x = array(1, 2, 3);
|
|
|
|
function __call($m, $a) {
|
|
print "Method $m called:\n";
|
|
var_dump($a);
|
|
return $this->x;
|
|
}
|
|
}
|
|
|
|
$foo = new Caller();
|
|
$a = $foo->test(1, '2', 3.4, true);
|
|
var_dump($a);
|
|
?>
|
|
|
|
|
|
Changes in the Zend Engine 1.0
|
|
|
|
The Zend Engine was designed from the ground up for increased speed,
|
|
reduced memory consumption and more reliable execution. We dare say
|
|
it meets all of these goals and does so pretty well. Beyond that,
|
|
there are several improvements in the language engine features:
|
|
|
|
* References support.
|
|
|
|
$foo = &$a; would make $foo and $a be two names to the same
|
|
variable. This works with arrays as well, on either side; e.g.,
|
|
$foo = &$a[7]; would make $foo and $a[7] be two names to the
|
|
same variable. Changing one would change the other and vice
|
|
versa.
|
|
|
|
* Object overloading support.
|
|
|
|
This feature allows various OO libraries to use the OO notation
|
|
of PHP to access their functionality. Right now, no use is made
|
|
of that feature, but we'd have a COM module ready by the time
|
|
PHP 4.0 is released. A CORBA module would probably follow.
|
|
|
|
* include() and eval() are now functions, and not statements.
|
|
|
|
That means they return a value. The default return value from
|
|
include() and eval() is 1, so that you can do if (include())
|
|
without further coding. The return value may be changed by
|
|
returning a value from the global scope of the included file or
|
|
the evaluated string. For example, if 'return 7;' is executed in
|
|
the global scope of foo.inc, include('foo.inc') would evaluate
|
|
to 7.
|
|
|
|
* Automatic resource deallocation.
|
|
|
|
Several people have been bitten by the fact that PHP 3.0 had no
|
|
concept of reference counting. The Zend Engine adds full
|
|
reference counting for every value in the system, including
|
|
resources. As soon as a resource is no longer referenced from
|
|
any variable, it is automatically destroyed to save memory and
|
|
resources. The most obvious example for the advantage in this is
|
|
a loop that has an SQL query inside it, something like '$result
|
|
= sql_query(...);'. In PHP 3.0, every iteration resulted in
|
|
another SQL result-set allocated in the memory, and all of the
|
|
result sets weren't destroyed until the end of the script's
|
|
execution. With the Zend Engine, as soon as we overwrite an old
|
|
result set with a new one, the old result set which is no longer
|
|
referenced, is destroyed.
|
|
|
|
* Full support for nesting arrays and objects within each other,
|
|
in as many levels as you want.
|
|
|
|
* true and false are now constants of type boolean.
|
|
|
|
Comparing any other value to them would convert that value to a
|
|
boolean first, and conduct the comparison later. That means, for
|
|
example, that 5==true would evaluate to true (in PHP 3.0, true
|
|
was nothing but a constant for the integer value of 1, so
|
|
5==true was identical to 5==1, which was false).
|
|
|
|
* Runtime binding of function names.
|
|
|
|
This complex name has a simple explanation - you can now call
|
|
functions before they're declared!
|
|
|
|
* Added here-docs support.
|
|
|
|
* Added foreach.
|
|
|
|
Two syntaxes supported:
|
|
|
|
foreach(array_expr as $val) statement
|
|
foreach(array_expr as $key => $val) statement
|
|
|
|
* A true unset() implementation.
|
|
|
|
A variable or element that is unset(), is now sent to oblivion
|
|
in its entirely, no trace remains from it.
|
|
|
|
* Output buffering support.
|
|
|
|
Use ob_start() to begin output buffering, ob_end_flush() to end
|
|
buffering and send out the buffered contents, ob_end_clean() to
|
|
end buffering without sending the buffered contents, and
|
|
ob_get_contents() to retreive the current contents of the output
|
|
buffer. Header information (header(), content type, cookies) are
|
|
not buffered. By turning on output buffering, you can
|
|
effectively send header information all throughout your file,
|
|
regardless of whether you've emitted body output or not.
|
|
|
|
* Full variable reference within quoted strings:
|
|
|
|
${expr} - full indirect reference support for scalar
|
|
variables
|
|
{variable} - full variable support
|
|
|
|
For example:
|
|
|
|
$foo[5]['bar'] = 'foobar';
|
|
print "{$foo[5]["bar"]}"; // would print "foobar"
|
|
|
|
* Ability to call member functions of other classes from within
|
|
member functions or from the global scope.
|
|
|
|
You can now, for example, override a parent function with a
|
|
child function, and call the parent function from it.
|
|
|
|
* Runtime information for classes (class name, parent, available
|
|
functions, etc.).
|
|
|
|
* Much more efficient syntax highlighter - runs much quicker,
|
|
performs more reliably, and generates much tighter HTML.
|
|
|
|
* A full-featured debugger has been integrated with the language
|
|
(supports breakpoints, expression evaluation, step-in/over,
|
|
function call backtrace, and more).
|
|
|
|
The Zend Engine claims 100% compatability with the engine of PHP
|
|
3.0, and is shamelessly lying about it. Here's why:
|
|
|
|
* Static variable initializers only accept scalar values
|
|
(in PHP 3.0 they accepted any valid expression). The impact
|
|
should be somewhere in between void and non existent, since
|
|
initializing a static variable with anything but a simple
|
|
static value makes no sense at all.
|
|
|
|
* The scope of break and continue is local to that of an
|
|
include()'d file or an eval()'d string. The impact should
|
|
be somewhat smaller of the one above.
|
|
|
|
* The return statement no longer works from a require()'d file. It
|
|
hardly worked in PHP 3.0, so the impact should be fairly small. If
|
|
you want this functionality - use include() instead.
|
|
|
|
* unset() is no longer a function, but a statement.
|
|
|
|
* The following letter combination is not supported within
|
|
encapsulated strings: "{$". If you have a string that includes
|
|
this letter combination, for example, print "{$somevar"; (which
|
|
printed the letter { and the contents of the variable $somevar in
|
|
PHP 3.0), it will result in a parse error with the Zend Engine.
|
|
In this case, you would have to change the code to print
|
|
"\{$somevar"; This incompatability is due to the full variable
|
|
reference within quoted strings feature added in the Zend
|
|
Engine.
|