# Moved the freeing of overriden functions to a point after the check.
# The new check comes after the normal inheritance check to give the first check
# the opportunity to abort with a more detailed error.
# Also fixed a small type in an unrelated test.
# The handling of legacy constructors defined by traits was corrected.
# They are now properly registered and used on instantiation.
# The situation for conflicting legacy and __construct constructors is
# mostly identical. If they are defined in the class, they override conflicts
# and do not collide. However, in case different styles are mixed, between
# class and trait definition, we assume a programmer's mistake and report
# a collision.
#
# BTW: +1 for all the fixed tests! `make test` is fun again.
# The method got unconditionally deleted from the class, since it was assumed that we override it, but we did not in case of abstract methods coming from a trait. Thus, dont delete when we try to merge in an abstract method.
# __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.
# Bug was uncovered by discussion in http://news.php.net/php.internals/54129
# Forgot to check the actual value of the initializer comparison, only checked
# whether comparison was successful which is not enough.
- missed a failing Traits test, but is now fixed, and the bug covered by a dedicated test
# Should always comment conditions that go over more than two lines :-/
#This change is made to have all possible cases of collisions consistently handled as fatal errors.
#The reason to have it fatal is that most likely something changed unexpectedly and needs urgent attention by the developer, since it will fail eventually anyway for instance because the expected method is missing in the class.
#Discussed in this thread: http://marc.info/?l=php-internals&m=129155790226876
#Please review this change, I moved the routine which copies statics from the closure code to zend_variables.c
#Please also have a look to check whether the TSRMLS_DC is correct, and whether it fits with the rest in zend_variables, because there you are using some macro magic and I am not exactly sure what the reason is for that.
#That was suggested several times already, but am still not sure whether that really reads better.
#Especially since only the trait is mentioned, since the method name would be duplicated anyway.
