Re: 5.4a2 trait attribute name conflict resolution
Hi Alex:
On Fri, Jul 22, 2011 at 7:46 PM, Alex Howansky <[email protected]> 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
Thread (18 messages)