Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51201
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain gmail.com does not designate 208.113.200.5 as permitted sender)
Message-ID: <4D21415A.10002@gmail.com>
Date: Mon, 03 Jan 2011 12:24:10 +0900
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7
MIME-Version: 1.0
To: internals@lists.php.net
References: <89C52156-CF92-4DDB-8BA4-4ABF6883512C@stefan-marr.de>
In-Reply-To: <89C52156-CF92-4DDB-8BA4-4ABF6883512C@stefan-marr.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Traits and Properties
From: davidkmuir@gmail.com (David Muir)

On 12/12/10 01:47, Stefan Marr wrote:
> Hi:
>
> Traits do not provide any special provisioning for handling properties, especially, there is no language solution for handling colliding property names.
> The current solution/idiom for handling state safely in a trait is to use either abstract set/get methods or an abstract get that returns a reference to the property in the class.
>
> However, at the moment it is possible to define properties in a trait:
>
> trait Foo {
>   private $a;
>   public  $foo;
> }
>
> For the moment, that information is completely ignored, thus:
>
> class Bar {
>   use Foo;
> }
> property_exists('Bar', 'a') === false
>
>
> Well, and that is a rather inconsistent status-quo.
>
> I would like to have that fixed in one or another way.
>
> One possibility would be to forbid property definition in a trait altogether.
> That reduces a bit the possibility to have wrong expectations about properties, however, the dynamic property creation is still possible.
>
> Another way would be to merge the properties in the composing class.
> The question here would be how to treat visibility modifiers: how to merge public and private, should it result in public, or private?
> And, to discorage users to go this way, should there be a STRICT notice? Options here are a notice whenever a property is defined in a trait, or whenever properties are silently merged.
>
>
> Comments very welcome.
>
> Thanks
> Stefan
>

What about extending the way that traits resolve method conflicts to 
solve property conflicts in a similar fashion? I can't remember if it's 
already been suggested and and maybe shot down already. It would 
probably get horrendously messy, but figured I'd mention it anyway.

Cheers,
David