Keep in mind that Traits are not Roles. Traits provide much more functionality than Roles do, in fact, they solve most of the things on your list.
Any trait can have a list of methods in @REQUIRES and those methods must be provided by either another trait or the consuming class.
If the conflict occurs during trait composition, the method in conflict is added ot the @REQUIRES array to be satisfied later.
You can also avoid conflict in two possible ways; 1) rename a method, or 2) exclude a method (which then adds the method to the @REQUIRES array). This is done by the consuming class/trait during compile time.
Conflicts cannot occur during class composition though, they can only happen between traits. However, if they do happen between traits, and there are methods in the @REQUIRES which are not satisifed by the consuming class, then BOOM your program does at compile time.
See above
B can resolve it (if it makes sense to do so), or it can leave it a "conflict in statis" (aka - @REQUIRES). Keep in mind that Traits (and Roles) will just not be the black boxes that classes are (supposed) to be. In fact, it is probably best to not look at Traits/Roles as being just a "name", but being an entire signature, meaning a name + method list.
Traits do not have a direct notion of private methods, however, they are easily accomplished. One possible approach is to use an anon-sub, which would assure the privacy, another would be to ask Ovid to provide some kind of support for them :)
Nope, method conflicts in Class::Trait are checked in 2 ways. First we check the name of the method, then if they are the same name, we compare them by strigifying their references, if they are different, then we have a conflict, if they are the same, then we don't. This means that Class::Trait sees the D methods in B and C as the same method, and therefore not a conflict.
Traits are not composable at runtime. Problem solved ;)
Yes, I know a lot of those questions have answers. stvn has done a lot of work in Class::Traits, in his work on the Perl6 metamodel, and in helping me write Perl6::Roles. In all that, he's come up with some darn good answers to a bunch of those questions. That doesn't mean that his answers are complete. And, frankly, his answers may be wrong for some situations.
Well, you are absolutely correct, in many situations my answers might be wrong. However, many of my answers are actually me just repeating things I have read which were written by people waaaaay smarter than I will ever be. Not that I assume those people are any more "right", but that they have given it much deeper thought that I have/can. Standing on the shoulders of giants and all that :)
It is also important that you keep Traits and Roles distinct in your mind. Roles are a limited version of Traits with many (IMO) important features missing. And as you well know, those missing features make things much more complicated since you need to make so many assumptions.
(Note: stvn doesn't use traits in his production work ... maybe that's a sign that traits aren't ready for primetime.)
There are a number of reasons for that, but mostly it came down to the fact that (at the time) I did not know how to really properly use Traits. In fact, I am still unsure of how to best utilize them, although Ovid's current usage in his testing work has given me some ideas. I think Traits/Roles requires that you re-wire your brain somewhat, and sometimes production work is not always the best place to test out that re-wiring.
In reply to Re^2: Informal Poll: why aren't you using traits?
by stvn
in thread Informal Poll: why aren't you using traits?
by Ovid
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |