From that follows that traits override the super class's methods.
And, conflict resolution is only done between traits, not between a class
and its traits.
The class body is a definite thing. Why would you purposefully add
something to a class body that conflicts with a trait?
The class needs to know exactly what the traits are doing. There is no
black-box reuse.
But that's precisely my point. No class would *purposefully* add something
to conflict with a trait. Then by your own description the only case is
*accidentally* adding something to conflict with it. In such a case why on
Earth is it allowed without a fatal error?
The use case for overriding is typically that you got a conflict that you
need to resolve by making a call to both conflicting methods.
Consider two traits that happen to provide a log() function, and in the
resulting class you need to call both in all places log() has been called
before.
Since the user of these traits is the only place where such semantic is
sensibly defined, the method in the class body is overriding the traits
methods, and can access aliases you
introduced for the traits' methods.
The way it works right now, on conflict, a class may access the trait method
via the alias, or its own overriden copy by the conflicting name.
What is a trait to do? It can't access its own method at all as it doesn't
"know" the alias.
The way this is implemented makes no sense, I'm afraid.
Let's use your example and make something more complex out of it:
trait T {
function bar(){ $this->print();
$str = 'print';
$this->$str(); }
function print() { echo 'trait'; }
}
> class C {
use T { print as foo; }
}
What is supposed to happen in this example if we assume renaming?
Would you expect the first function call to print() in bar() to work after
the renaming?
Would you expect the second call, using metaprogramming, to work as well?
It's very simple:
1) *only* the original name should work for methods defined in a trait
(including metacalls).
2) *only* the new name should work from methods defined in the using class
(including metacalls).
Yes, I know: this is a lot more complicated to implement. *But* if we'll
take shortcuts in user-facing behavior just because it's simpler to
implement, then aliasing should've have never been added at all for 5.4,
until it can be implemented reasonably.
If we use aliasing instead of renaming, we have predictable behavior for
all options.
It's not predictable at all. If the class defines "function print" in your
example above, the trait suddenly can't call it's own method anymore!
Metacall or not.
Please do me the favor and consult the mailing list archives.
It is all in the various discussions.
If behavior specification and reasoning worked by consulting the archives
for internals, we wouldn't have RFCs. I see no good reasoning in the RFC for
this behavior, and going though thousands of emails in the archive is not a
reasonable way to find out the reasoning.
There is no proper way to handle state, state requires splitting, merging,
and what not. None of the research prototypes provides a simple solution.
State does not require splitting, merging. What does state "splitting" even
mean? Here's a very simple design principle here: if you can't guarantee
correctness for a behavior, provide a limited behavior, which guarantees
correctness. This is how language design works. If there's a conflict, die
with a fatal error, make people rename their properties so there's no
conflict.
Assuming *silently* that the user is intentionally colliding state variables
between traits because he/she wants to merge/split state is insanity IMO.
The solution we have is a 'best effort' solution.
If you can do better, please make a proposal.
I did in my original email. No property collisions. Fatal errors. It's very
simple.
I assume we are talking about:
http://php.net/manual/en/language.oop5.traits.php
Static variables and members/properties are not related at all. The writer
of the documentation didn't get the wording correct. Please feel free to
submit a patch.
I've submitted a doc bug. No one want to fix it since they think it's PHP
that's wrong, not the manual. I can't do anything more about it.
Here's the link: https://bugs.php.net/bug.php?id=62156
Stan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
