Fix #77291: magic methods inherited from a trait may be ignored #3707
Conversation
When adding methods from a trait, we must not assume that a method name with the same length as the name of the using class is either a PHP 4 style constructor, or not a magic method at all – it may well be another magic method. We preserve the spirit of the optimization which caused this regression, and avoid string comparisons for all method names which can never be magic methods.
|
Fun case: What happens if the class is also called |
|
Answer: https://3v4l.org/0KjBR It's treated as a ctor... |
| } | ||
| zend_string_release_ex(lowercase_name, 0); | ||
| } else if (ZSTR_VAL(mname)[0] != '_' || ZSTR_VAL(mname)[1] != '_') { | ||
| if (ZSTR_LEN(ce->name) != ZSTR_LEN(mname) && (ZSTR_VAL(mname)[0] != '_' || ZSTR_VAL(mname)[1] != '_')) { |
There was a problem hiding this comment.
I think it would be better to extract the checking logic into a separate function (length + name comparison) and keep the check in this location (rather than moving to the end).
Fascinating! However, it seems to me this example is not about |
|
You're right, I was testing the wrong thing... In that case this patch LGTM. |
When adding methods from a trait, we must not assume that a method name
with the same length as the name of the using class is either a PHP 4
style constructor, or not a magic method at all – it may well be
another magic method.
We preserve the spirit of the optimization which caused this
regression, and avoid string comparisons for all method names which can
never be magic methods.