hi,
Would it be possible to somehow document what you are discussing here?
It is not too easy to keep track of all discussions about traits
(along other things). Maybe in draft RFC or a simple page in the wiki.
Doing so will help to have a quick view about the open questions or
recent changes/propositions.
Thanks!
On Sat, Dec 11, 2010 at 5:47 PM, Stefan Marr <p...@stefan-marr.de> 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
>
> --
> Stefan Marr
> Software Languages Lab
> Vrije Universiteit Brussel
> Pleinlaan 2 / B-1050 Brussels / Belgium
> http://soft.vub.ac.be/~smarr
> Phone: +32 2 629 2974
> Fax: +32 2 629 3525
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
