Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61919
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fmethod.com from 74.125.83.42 cause and error)
Message-ID: <F35ED36746E94901A94CF4F6D2C4EB93@pc>
To: "Stefan Marr" <php@stefan-marr.de>
Cc: <internals@lists.php.net>
References: <232501B15F7F4B3197123F219370E36D@pc> <A9048740-0311-4A3E-AF7A-77650F997790@stefan-marr.de> <2125641B4C7D4D6E8616F86C9C5563D2@pc> <5D98E000-D40D-43EC-9C94-D5B00331C82E@stefan-marr.de>
Date: Wed, 1 Aug 2012 15:56:59 +0300
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Traits behavior still up in the air in 5.4
From: sv_forums@fmethod.com ("Stan Vass")

> 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