- Extensions which delete global variables need to use new special function
- delete_global_variable() (I'm about to rename it) to remove them.
- Will post to internals@ or via commit messages if there's anything else.
a) We specialize opcodes according to op_type fields. Each opcode has to
be marked with which op_type's it uses.
b) We support different execution methods. Function handlers, switch()
and goto dispatching. goto seems to be the fastest but it really
depends on the compiler and how well it optimizes. I suggest playing
around with optimization flags.
- Warning: Things might break so keep us posted on how things are going.
(Dmitry, Andi)
- Perform implementation checks even with simple inheritance (off when
compatibility mode is enabled).
- Restore default arguments in interfaces and handle it correctly.
- Move registration of internal classes later in the startup sequence
in order to have INI options available.
- Enforce exceptions to be derived from class Exception. This allows
users to perform catch-all. It's not yet complete, so don't get
comfortable with it just yet :) Updates are coming soon.
- Implement zend_throw_exception() using zend_throw_exception_ex()
Note that this is available for downwards compatibility only - and it doesn't
work if you use new features (namely, interfaces). Generally, people should
declare their classes before using them, but we just didn't want hell to break
loose (c)
implementation, and allows exceptions to 'fire' much earlier than before.
Instructions on how to use the new mechanism will follow on internals@
shortly...
Note - this (most probably) breaks the current implementation of
set_exception_handler()
internal non-static methods statically.
# As discussed with Zeev:
# - For BC standard userspace methods allow this with an E_STRICT message.
# - If you want to implement an internal method taht can be called both
# statically and non-statically then use flag ZEND_ACC_ALLOW_STATIC.
# - Magic user space methods __*() cannot and __construct, __destruct,
# __clone can never be called statically.
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.