Larry Wall writes:
> But if you say something like:
>
> class DangerousPet does Pet does Predator {
> multi method feed ($x) {...}
> }
>
> then DangerousPet::feed is called only when multimethod dispatch
> would have thrown an exception. Alternately, multi's will probably have
> some way of identifying the default method in any case, so maybe you
> have to write it something like this:
>
> class DangerousPet does Pet does Predator {
> multi method feed ($x) is default {...}
> }
>
> that leaves the door open for real multi's within the class working
> in parallel to the roles' methods:
>
> class DangerousPet does Pet does Predator {
> multi method feed ($x) is default {...}
> multi method feed (DangerousPetFood $x) {...}
> }
>
> Arguably, the role's might be required to declare their methods "multi"
> if they want to participate in this, but that's one of those things
> that feel like they ought to be declared by the user rather than the
> definer. On the other hand, maybe a role would feel that its method
> *must* be unique, and leaving out the "multi" is the way to do that.
> But I hate to get into the trap of culturally requiring every method
> in every role to specify "multi". It's a little too much like the C++
> ubiquitous-const problem.
I'd like that roles don't have control over whether their methods are
unique, but the class does. That is, multi dispatch would be one of the
several disambiguation possibilities for role conflicts. But without
specification, name conflicts always result in error.
> [...]
>
> My hope for unifying traits and superclasses is that, if you call an
> ordinary class using "is", the wicked thing that it does is insert
> itself into the "ISA" property of the class. Where that may cause
> problems if you want to inherit from an existing trait that does
> something else wicked. But then, traits aren't often going to be
> inherited anyway, since their purpose is to break the rules. We can
> maybe inherit from classof(trait) to get around any difficulties.
> So I'm still thinking we do inheritance with "is" rather than "isa".
> We just have to keep our names straight. Generally, traits will
> be lowercase, and true class or role names start with an uppercase
> letter.
I like that. That allows for nice things like letting a class keep
track of its subclasses, or in general doing other tricky things to its
subclasses.
Inheritance is a logical association, not a functional one, so when
your classes are doing nonstandard things, you'd like to modify what
inheritance does. Definitely good.
Luke
