# __TRAIT__ behaves like __CLASS__ more or less but is constraint to traits.
# Since traits are not types, there are not many valid use cases, and trying
# to use __TRAIT__ to make traits more like classes is discouraged.
# __TRAIT__ behaves like __CLASS__ more or less but is constraint to traits.
# Since traits are not types, there are not many valid use cases, and trying
# to use __TRAIT__ to make traits more like classes is discouraged.
# RFC http://wiki.php.net/rfc/horizontalreuse#traits_-_reuse_of_behavior
# Ok, here we go, I guess that will result in more discussion, which is fine
# by me. But now, the patch is here, and properly archived.
#
# See below a list of notes to the patch, it also includes a list of
# points which should be fixed
#
# Internals of the Traits Patch
# -----------------------------
#
# Open TODOs
# """"""""""
#
# - Reflection API
# - support for traits for internal classes
# - currently destroy_zend_class does not handle that case
#
# Introduced Structures
# """""""""""""""""""""
#
# Data structures to encode the composition information specified in the
# source:
# - zend_trait_method_reference
# - zend_trait_precedence
# - zend_trait_alias
#
# Changes
# """""""
#
# zend_class_entry
# - uses NULL terminated lists of pointers for
# - trait_aliases
# - trait_precedences
# - do you prefer an explicit counter?
# - the information is only necessary during class composition
# but might be interesting for reflection
# - did not want to blow up class further with not really necessary length counters
#
# added keywords
# - trait
# - insteadof
#
# Added opcodes
# ZEND_ADD_TRAIT
# - similar to ZEND_ADD_INTERFACE
# - adds the trait to the list of traits of a class, no actual composition done
# ZEND_BIND_TRAITS
# - emitted in zend_do_end_class_declaration
# - concludes the class definition and will initiate the trait composition
# when the class definition is encountered during runtime
#
# Added Flags
# ZEND_ACC_TRAIT = 0x120
# ZEND_ACC_IMPLEMENT_TRAITS = 0x400000
# ZEND_FETCH_CLASS_TRAIT = 14
#
# zend_vm_execute.h
# - not sure whether the handler initialization (ZEND_ADD_TRAIT_SPEC_HANDLER,
# ZEND_BIND_TRAITS_SPEC_HANDLER) is correct, maybe it should be more selective
#
# zend_compile.c
# - refactored do_inherit_method_check
# split into do_inherit_method_check and do_inheritance_check_on_method
# - added helper functions use a '_' as prefix and are not mentioned in the
# headers
# - _copy_functions
# prepare hash-maps of functions which should be merged into a class
# here the aliases are handled
# - _merge_functions
# builds a hash-table of the methods which need to be added to a class
# does the conflict detection
# - reused php_runkit_function_copy_ctor
# - it is not identical with the original code anymore, needed to update it
# think I fixed some bugs, not sure whether all have been reported back to runkit
# - has to be renamed, left the name for the moment, to make its origin obvious
# - here might be optimization potential
# - not sure whether everything needs to be copied
# - copying the literals might be broken
# - added it since the literals array is freed by efree and gave problems
# with doubled frees
# - all immutable parts of the zend_op array should not be copied
# - am not sure which parts are immutable
# - and not sure how to avoid doubled frees on the same arrays on shutdown
# - _merge_functions_to_class
# does the final merging with the target class to handle inherited
# and overridden methods
# - small helper for NULL terminated lists
# zend_init_list, zend_add_to_list
#
# zend_language_parser.y
# - reused class definition for traits
# - there should be something with regard to properties
# - if they get explicitly defined, it might be worthwhile to
# check that there are no collisions with other traits in a composition
# (however, I would not introduce elaborate language features to control that
# but a notice for such conflicts might be nice to the developers)
. ZEND_RECV now always has IS_CV as its result
. ZEND_CATCH now has to be used only with constant class names
. ZEND_FETCH_DIM_? may fetch array and dimension operans in a different order
. Improved syntax highlighting and consistency for variables in double-quoted strings and literal text in HEREDOCs and backticks. (Matt)
. Optimized interpolated strings to use one less opcode. (Matt)
[DOC] "expr1 ?: expr1" is a shortcut for: "expr1 ? expr1 : expr2" as
exists in gcc and discussed some time back. Note that this is not
an implementation ifsetor($var, default). While ifsetor would not
generate any message for non existing variables or array indices
the ternary shortcut does. Also the ternary shortcut does a boolean
evaluation rather then checking for isset(). That way ther ternary
shortcut can work on any expression while ifsetor can only work on
variables. Also to be silent one has do do: "@$expr1 ?: $expr2".
- Fixed bug #36214 (__get method works properly only when conditional operator is used).
- Fixed bug #39449 (Overloaded array properties do not work correctly).
- Fixed bug #39990 (Cannot "foreach" over overloaded properties).
# This time i added:
# ZEND_FE_RESET_VARIABLE
# ZEND_FE_RESET_REFERENCE
# and dapted parser,compiler,executor,interfaces to handle these flags
# their purpose is to be able to pass whetehr foreach is done by ref to
# the current() handler so that it can error out in case it is not capable
# to comply to the requested return signature/protocol/semantics (weyp).
- 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.
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()
implementation.
Using clone directly is now done using
$replica = clone $src;
Clone methods must now be declared as follows:
function __clone($that)
{
}
Clone methods in derived classes can call the __clone method of their parent
classes using parent::__clone($that)
- declerations. Allowing the access of other constants in this code is
- flawed. We are reverting back to PHP 4's static scalars.
- Don't worry if you get the following msg when compiling:
- "zend_language_parser.y contains 3 useless nonterminals and 22 useless rules"
- I didn't nuke the code in case we have some brilliant ideas after beta 2
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.
- 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.
avoid making developers traverse the entire class/interface hierarchy
before they can figure out whether a class is instantiable
(ok, so it makes sense :)
