Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61914
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fmethod.com from 209.85.215.170 cause and error)
Message-ID: <2125641B4C7D4D6E8616F86C9C5563D2@pc>
To: "Stefan Marr" <php@stefan-marr.de>
Cc: <internals@lists.php.net>
References: <232501B15F7F4B3197123F219370E36D@pc> <A9048740-0311-4A3E-AF7A-77650F997790@stefan-marr.de>
Date: Wed, 1 Aug 2012 14:54:05 +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")

> 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