file/line/message info if possible.
- Add zend_eval_string_ex() to be able to handle exceptions in eval'd code.
- Use above function to fix memleaks in CLI.
zend_call_function() now takes a structure that should contain all of the
necessary information. If further information is necessary in the future,
then we'll be able to add it without having to introduce a new function.
As for caching - the 2nd, optional argument is a struct that can hold all
of the information that's necessary to invoke the function, including its
handler, scope and object it operates on (if any). Note that you may only
use a cache if the arguments you provide to zend_call_function() are
identical to the ones of the last call, except for the argument and return
value information.
The recently introduced fast_call_user_function() was removed
I fixed most of the places that used fast_call_user_function() to use caching
but there are still some that need to be fixed (XML and reflection)
including:
- Whether or not to pass by ref (replaces the old arg_types, with arg_info)
- Argument name (for future use, maybe introspection)
- Class/Interface name (for type hints)
- If a class/interface name is available, whether to allow a null instance
Both user and builtin functions share the same data structures.
To declare a builtin function that expects its first arg to be an instance
of class 'Person', its second argument as a regular arg, and its third by
reference, use:
ZEND_BEGIN_ARG_INFO(my_func_arg_info, 0)
ZEND_ARG_OBJ_INFO(0, someone, Person, 1)
ZEND_ARG_PASS_INFO(0)
ZEND_ARG_PASS_INFO(1)
ZEND_END_ARG_INFO();
and use my_func_arg_info as the arg_info parameter to the ZEND_FE() family
of macros.
The first arg to each ZEND_ARG_*() macro is whether or not to pass by ref.
The boolean arg to ZEND_BEGIN_ARG_INFO() tells the engine whether to treat
the arguments for which there's no explicit information as pass by reference
or not.
The boolean argument to ZEND_ARG_OBJ_INFO() (4th arg) is whether or not to allownull values.
Supply a dup version (like estrdup).
Fix tolower() handling.
# Havin copy and dup allows to use the faster version even with
# memory not allocated by emalloc.
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...
@ catch-all exception handling function (Stig)
- Added set_exception_handler() function for registering a global,
catch-all exception handling function (Stig)
- Again I hope this feature ends up working well because if it doesn't we
- might need to nuke it. This only works for global scoped classes and it
- will never work for sub-classes so don't even ask!!!!!
- Just define an __autoload() function in the global scope and it will be
- called with the class name as the parameter if it doesn't manage to find
- the class.
There are still a few problems such as includes and calling other functions
from internal functions which aren't seen (will have to think if and how to
fix this).
Also the main scripts filename isn't available. Need to think about that.
Note: only standard Zend objects are working now. This is definitely going to
break custom objects like COM, Java, etc. - this will be fixed later.
Also, this may break other things that access objects' internals directly.
- 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.