> 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 <ahar...@php.net> wrote: > On 22 July 2011 09:12, Alex Howansky <alex.howan...@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 > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
