Re: 5.4a2 trait attribute name conflict resolution

Hi Alex: On Fri, Jul 22, 2011 at 7:46 PM, Alex Howansky <alex.howansky@gmail.com> wrote: > >> Best practice, always choose trait property names carefully/~unique >> so that you don't run into conflicts. > > Sure, but in this case, I created the conflict intentionally because I > *want* to override it, and I'm not allowed to like I am with methods. Don't > you think that's inconsistent? > >> The short answer is it's not a bug but maybe an implementation >> issue... should it be an E_WARNING instead of E_STRICT? > > At least. Consider the situation where I'm using classes/traits from > somebody else's library that I may not be intimately familiar with. I'll > have to know what every one of their properties is named so I can plan my > code accordingly -- else I'll silently start getting their values in what I > think are my variables. If their trait grows that complex, with its own set of invariants, it is a clear sign that it should be a class instead. Traits are supposed to be a very light-weight mechanism for reuse of behavior. Classes already provide you with the necessary means of encapsulation you are asking for here: but traits do not do that. If you want to reuse a trait that is that complex, consider to use it in a separate class, which is then used in a composition in the class were you originally were going to use the trait directly. Traits do not allow to be reused without knowing their internals. The metaphor of a compiler-assisted copy'n'past mechanism hints at that. At least that is my interpretation of the topic. Best regards Stefan