Abhijit A. Mahabal writes: > On Fri, 19 Dec 2003, Larry Wall wrote: > > > On Fri, Dec 19, 2003 at 10:23:45AM -0800, Austin Hastings wrote: > > : Of course, when I do: > > : > > : my $x = 0 but (true|false); > > : > > : then what happens? > > > > That's the problem with making them methods. Any such operational > > definition is going to get you in trouble. I think I like them better > > as enums, because then you can have junctions of them functioning as > > a kind of subtype. > > Is that thought about just traits, or also about roles?
Neither. It's just about roles. We're having another vocabulary conflict; refer to the vocabulary doc. > Sometime earlier Larry mentioned that roles could add multimethods, > and my worry about that is this: > If you simultaneously have a multi method with a signature and > another without, given a particular call to this multimethod how do you > choose which of the two happens if the signature matches? Probably the same way you disambiguate when normal multimethods abound. The more specific signature wins, if it matches. Though I do see how this might introduce subtle bugs. I'm a big fan of method name-only equivalence, so I would argue that it overrides (or subsides if it isn't being slathered on), but then I don't have experience with large-scale projects. > Disallowing such clashes seems problematic because it may mean that if > the class writer used types and signatures these get forced onto the > user of the class. Everybody's going to be using signatures, though! (Types are a different story) Yeah, the typeless one would win, I think, unless the type happens to be Any. Luke
