Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:54154
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.42 as permitted sender)
MIME-Version: 1.0
Reply-To: php@stefan-marr.de
Sender: stefan.marr.de@gmail.com
In-Reply-To: <4E29B780.1030009@gmail.com>
References: <4E29949C.9020209@gmail.com>
	<004701cc4890$f9d63f80$ed82be80$@com>
	<4E29B780.1030009@gmail.com>
Date: Sat, 23 Jul 2011 15:57:20 +0200
Message-ID: <CA+2ZKBZ1JvOJ0Zn90b54s0sRLEaS5rUT5A1dB7drL3tD79FmMw@mail.gmail.com>
To: Alex Howansky <alex.howansky@gmail.com>
Cc: internals@lists.php.net
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] 5.4a2 trait attribute name conflict resolution
From: php@stefan-marr.de (Stefan Marr)

Hi Alex:

On Fri, Jul 22, 2011 at 7:46 PM, Alex Howansky <alex.howansky@gmail.com> wrote:
>
>> Best practice, always choose trait property names carefully/~unique
>> so that you don't run into conflicts.
>
> Sure, but in this case, I created the conflict intentionally because I
> *want* to override it, and I'm not allowed to like I am with methods. Don't
> you think that's inconsistent?
>
>> The short answer is it's not a bug but maybe an implementation
>> issue... should it be an E_WARNING instead of E_STRICT?
>
> At least. Consider the situation where I'm using classes/traits from
> somebody else's library that I may not be intimately familiar with. I'll
> have to know what every one of their properties is named so I can plan my
> code accordingly -- else I'll silently start getting their values in what I
> think are my variables.

If their trait grows that complex, with its own set of invariants, it
is a clear sign that it should be a class instead.
Traits are supposed to be a very light-weight mechanism for reuse of behavior.
Classes already provide you with the necessary means of encapsulation
you are asking for here: but traits do not do that.

If you want to reuse a trait that is that complex, consider to use it
in a separate class, which is then used in a composition in the class
were you originally were going to use the trait directly.

Traits do not allow to be reused without knowing their internals. The
metaphor of a compiler-assisted copy'n'past mechanism hints at that.

At least that is my interpretation of the topic.

Best regards
Stefan