Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51202
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain yahoo.com.au from 98.139.91.228 cause and error)
DomainKey-Status: good
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com.au;
  h=DKIM-Signature:Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding;
  b=Lu+ka6KJXgjlnW3zvqlDZAjTFweBlu4xLyxSI7ksPBzcpK5zCfw9Xs5dtUz+v708Jge1WL7KwEQwNvvK0X5DTHxeGBCOh5hwLAWQNTjuksFt3ihrctbW1LNwPE8dpBmOQ+eA4v1ADZb3bpllaMvhjKqu9/hB9MbegcTZLHkT3GY=  ;
Message-ID: <4D21658A.2030208@yahoo.com.au>
Date: Mon, 03 Jan 2011 16:58:34 +1100
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 ThunderBrowse/3.3.4
MIME-Version: 1.0
To: internals@lists.php.net
References: <89C52156-CF92-4DDB-8BA4-4ABF6883512C@stefan-marr.de> <4D21415A.10002@gmail.com>
In-Reply-To: <4D21415A.10002@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Traits and Properties
From: mail_ben_schmidt@yahoo.com.au (Ben Schmidt)

On 3/01/11 2:24 PM, David Muir wrote:
> 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

I'm a latecomer here, but...

Stefan, doesn't this conflict with what you've written here (and the
test cases in SVN)?:

http://wiki.php.net/rfc/horizontalreuse#handling_of_propertiesstate

Or is what is happening here that the properties in traits are treated
essentially as declarations rather than definitions, triggering errors
but not actually creating properties, and you think they should actually
create properties?

Ben.