Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:54155
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: <007901cc489f$01d02580$05707080$@com>
References: <4E29949C.9020209@gmail.com>
	<004701cc4890$f9d63f80$ed82be80$@com>
	<4E29B780.1030009@gmail.com>
	<007901cc489f$01d02580$05707080$@com>
Date: Sat, 23 Jul 2011 15:58:36 +0200
Message-ID: <CA+2ZKBaAF2NdhLx7+t_Y+zGu9GSEUutKsSmZhyorwC7csB=WfQ@mail.gmail.com>
To: Jonathan Bond-Caron <jbondc@openmv.com>
Cc: Alex Howansky <alex.howansky@gmail.com>, 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)

On Fri, Jul 22, 2011 at 8:41 PM, Jonathan Bond-Caron <jbondc@openmv.com> wrote:
> On Fri Jul 22 01:46 PM, Alex Howansky wrote:
>>
>> 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?
>>
>
> Agree

I do not agree, because for methods there is for most cases a way
around. You can introduce a new alias for the same behavior and use
that from the method which is overriding the original method name of
the trait. Thus, there is a flexible way to compose behavior, and that
is what we do everyday.
State how ever, does not come with that property, and the last time we
discussed different ideas in that direction they were deemed to be
complex.

> So that traits can keep their own private state (Ben Schmidt's idea)

One of those ideas should definitely be reconsidered for a later
version of PHP, but for the moment, I would prefer to concentrate on
getting bug-free what we have already and gather some experience on
how it is actually used in real-world scenarios.
In the end, if you trait is to complex and can 'break' easily, I think
that shows that it is worth to be implemented as a class, and you
might use instead a trait that provides you with the necessary
delegation functions.

Best regards
Stefan