I started thinking again about why class methods silently override role (traits) methods. Since I see this pop up on mailing lists from time to time by programmers getting hurt by this or a variant of this, I kept wondering why on earth the traits researchers would recommend this. From the original traits paper we have the following:
Methods defined in the class take precedence over trait methods. This allows the glue methods defined in a class to override methods with the same name provided by the used traits.
After pondering the Perl community debate on this topic, I still couldn't see the point. Sure, let the class win, but silently? That still doesn't make sense to me. Finally, knowing that any information I got from the Perl community would be second-hand, I figured the only way I was going to get an answer would be to email the original researchers and find out their reasoning. I confess that their responses held some surprises. While the following is quoted from Dr. Andrew P. Black, one of the primary researchers in this field, the others in the discussion generally appeared to agree with his explanations (the following quotes are all his and presented here with permission):
Yes, it is really important that a programmer can see clearly when a trait method is being overridden — just as it is important that it is clear when an inherited method is being overridden.
So there you have it, right from the original researchers: class wins, but not silently. However, that raises the obvious issue of why this wasn't explicitly laid out in their papers? As it turns out, that's because they implemented this in Smalltalk.
In Smalltalk, where a program is viewed as a graph of objects, the obvious solution to this problem is to provide an adequate tool to show the programmer interesting properties of the program. The original traits browser did this for Smalltalk; the reason that we implemented it is that traits were really NOT a good idea (that is, they were not very usable or maintainable) without it. Since then, the same sort of "virtual protocols" have been built into the browser for other properties, like "overridden methods".
In short, the researchers felt traits would be a bad idea if the programmer couldn't explicitly see what was happening. However, this tool support is so integral to Smalltalk (you really should check it out), that adding behavior to the tools is second nature. The traits authors knew that this information needed to be immediately in front of the programmer, so they pushed it into their browser (kind of like the Smalltalk IDE) because that's as natural to them as a Perl programmer using map to transform a list.
When Smalltalk is in the browser, it's code, not just documents. Smalltalk, a dynamic language, gets around many of the parsing issues which Perl and other dynamic languages experience by having the code already compiled. You're not parsing a document, you're parsing the code. So what does this mean for languages where we parse documents? (Such a thing tends to be trivial in static languages like Java, but hard for dynamic languages):
If, on the other hand, you view a program as sheets of paper rather than objects, then the obvious solution is to add yet another language feature. So, Java, for example, realized (after about 10 years) that it needed an overrides annotation, and a compiler enhancement to issue a warning if a method overrides another without using the annotation. So they extended the language. Similarly, I agree that if the normal Perl environment does not provide good programming tools, then the implementation of traits for Perl ought to have done something to make it clear that a class method was overriding a trait method.
Make of that what you will. Personally, I don't use Perl::Critic and that's where the "notify when class wins" behavior was to be pushed (though I don't see it on the CPAN), so that's pretty useless to me. (Update: I phrased that very badly and I apologize to anyone I may have offended. See note below).
I don't know that this will necessarily cause movement on anyone's part, but it's nice to know I wasn't totally insane in my reasoning (though I originally wanted this to be a composition failure and was willing to compromise on a warning).