- The fields of zend_namespace were not completely initialized which
led to a variety of problems.
- The occurrence of class/interface/namespace definition is now
captured.
- Functions/classes/interfaces/namespaces can be preceded by doc
comments which are stored for use by extensions.
1. Nested classes are gone.
2. New syntax for namespaces:
namespace foo {
class X { ... }
function bar { ... }
var x = 1;
const ZZ = 2;
}
3. Namespaced symbol access: $x = new foo::X; - etc.
For now, namespaces are case insensitive, just like classes.
Also, there can be no global class and namespace with the same name
(to avoid ambiguities in :: resolution).
We need separate cleanup stage because of the following problem:
Suppose we destroy class X, which destroys function table,
and in function table we have function foo() that has static $bar. Now if
object of class X was assigned to $bar, its destructor will be called and will
fail since X's function table is in mid-destruction.
So we want first of all to clean up all data and then move to tables
destruction.
Note that only run-time accessed data need to be cleaned up, pre-defined
data can not contain objects and thus are not probelmatic.
# Looks like we are having a lots of pain in the various parts of the body
# because of the destructors...
- some fixes by me).
- You can't access protected variables from outside the object. If you want
- to see a protected member from your ancestors you need to declare the
- member as protected in the class you want to use it in. You can't
- redeclare a protected variable as private nor the other way around.
- destructor could be run after its class was already dead. Right now
- object destructors is the first thing whic happens during shutdown in
- order to prevent this problem. It's very likely that destructors will
- cause more grief and we'll have to outline exactly when you should use
- them and what kind of logic you're allowed to do inside of them.
- This bug was reported by sebastian.
Advantages:
- Smaller memory footprint for the op arrays
- Slightly faster compilation times (due to saved erealloc() calls and faster zend_op
initialization)
- include_once() & require_once() share the same file list
- Consistency between include() and require() - this mostly means that return()
works inside require()'d files just as it does in include() files (it used to
be meaningless in require()'d files, most of the time (see below))
- Made require() consistent with itself. Before, if the argument was not a constant
string, require() took the include() behavior (with return()).
- Removed lots of duplicate code.
Bottom line - require() and include() are very similar now; require() is simply an include()
which isn't allowed to fail. Due to the erealloc() calls for large op arrays, require()
didn't end up being any faster than include() in the Zend engine.
