Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:54139
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.210.44 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CADajX4Bipo6Syi_nG_+pbPzU=5Um2fdrxy8cCuZfyyXaniU7bA@mail.gmail.com>
References: <4E29949C.9020209@gmail.com>
	<CAKUjMCWWmhkQTMLoof76nFZEZs80cz4KFgKtw5UzsX6XwFMoVw@mail.gmail.com>
	<CAH8KiXK9z907NrPn4=v_P8iAUS+1NSMOXEe-nZpt1Mks43+YDw@mail.gmail.com>
	<4E29A164.3070108@gmail.com>
	<CADajX4Bipo6Syi_nG_+pbPzU=5Um2fdrxy8cCuZfyyXaniU7bA@mail.gmail.com>
Date: Fri, 22 Jul 2011 12:25:26 -0400
Message-ID: <CAAyV7nEOs_O6QQFz0CCDyhLspZVk75pbJ34duj6493JEmP2sZA@mail.gmail.com>
To: Adam Harvey <aharvey@php.net>
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: ircmaxell@gmail.com (Anthony Ferrara)

> Traits definitely need to be able to support properties, IMO

Well, if traits support properties, they stop being traits and become
mixins.  A trait is nothing more than a mixin that does not have a
state (so no properties).  I'm not saying that it wouldn't be useful
to contain properties (and hence state), but the RFC was for traits,
they are called traits, and the RFC does mention that they shouldn't
contain state.  So a trait (by definition) should be purely behavioral
(methods only).

So, based on that, it does indeed seem like a bug to me that they
currently support properties.

If properties are to be supported, then why don't we rename the trait
to a mixin and have some semblance of consistency...

Anthony

On Fri, Jul 22, 2011 at 12:18 PM, Adam Harvey <aharvey@php.net> wrote:
> On 22 July 2011 09:12, Alex Howansky <alex.howansky@gmail.com> wrote:
>>
>>> That makes sense if it would overwrite the methods as well, but
>>> otherwise it seems like it provides inconsistent functionality.
>>
>> Exactly. At the least, it's inconsistent. If it's a bug, then it seems the
>> question becomes:
>>
>> Is the bug this:
>>
>> "Properties defined in a trait should be overridden by same-named properties
>> defined in a class that use the trait."
>>
>> Or (as pointed out by Anthony) this:
>>
>> "You shouldn't be able to define properties in a trait."
>
> Traits definitely need to be able to support properties, IMO, so I'd
> say that the first behaviour just needs to be documented (and
> potentially a notice added). Either the trait or the class is going to
> have its property overwritten, so we should pick which definition wins
> and go from there.
>
> Adam
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>