The methods in the class have *always* higher precedence.
This is the same 'overriding' behavior used for inheritance.
From my personal perspective, changing this would lead to a major
inconsistency with how subclassing works.
Hi, I've subsequently read your RFC carefully and saw some of those items
are by design. However while they're by design, the end result seems rather
confusing I should say.
While I'm glad the RFC was shooting for consistency in general, traits are
not subclassing. Therefore aligning the behavior of features for vertical
reuse with features for horizontal reuse seems somewhat arbtirary to me. The
use cases for overriding methods like this seem sketchy at best. What is the
use case, and how are those use cases more important than the confusion
caused by allowig this?
2. Using "as" syntax when importing a trait does NOT rename a method, but
creates an alias CLONE, the original method still callable.
Proposed behavior: the original name should be only accessible within
the trait and its methods, not from the class methods or by calling the
class instance's methods from outside.
Again, this happens to be 'by design'.
PHP is a rather dynamic language, and we happen to have things like
$c->$foo();
where $foo is a string. Renaming is technically not reasonable, and would
also lead to major confusion when metaprogramming is used.
Can you please explain how are function names by variable at all related to
this? $object->foo() and $object->$foo() aren't even related in any way
semantically. If a conflict exists while grafting a trait, the original
method will be overshadowed silently and the method will be only accessible
by the alias. The entire idea of aliasing is to avoid a conflict with an
existing method of the same name. While if there's no collision, it's
accessible by both. So in practice it works by chance. How is "working by
chance" in any way aiding meta programming?
3. Properties silently collide in traits and classes.
Please read
https://wiki.php.net/rfc/horizontalreuse#handling_of_propertiesstate
carefully.
Again, this is intended behavior.
If you want to be notified of such collisions, please use E_STRICT.
I've read them carefully now, but there's no solid reason given for this
behavior, or why the proper behavior only exists in E_STRICT.
I can't really see "state is a complex topic" as a reason why trait property
collisions are handles inconsistently with method collisions.
4. The documentation says static propeties can't be defined by traits.
Yet they can.
I don't know what's the bug here: a doc bug, or a code bug. For
consistency, static properties should work, if instance properties work.
Nothing is gained supporting it half-way.
Could you please point me *exactly* to the paragraph where we have
something written about static properties? I do not see that I wrote
anything special about static properties in the >RFC. And I do not find it
in the docs either. static properties should work like normal properties.
Sure. From the manual page for traits: "Static variables can be referred to
in trait methods, but cannot be defined by the trait." This paragraph is
then following by a code example using function-static variables as what
seems like an example for a replacement for static trait properties,
strongly suggesting the former aren't supported. Yet they are.
The RFC seems to also give examples of method-level static variables, and I
honestly can't see how this is related to traits or trait/class-level
members at all.
Stan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
