If this were Java, the way to do this would be to define a Thingie
interface, and then an (archetypical) ThingieObject class... any time
that we want to actually *create* Thingies, we would use "new
ThingieObject", but everywhere else, we would use the typename
"Thingie". This way, when we want a class which "acts like" a Thingie,
but without inheriting any of it's innards, simply implement the Thingie
interface, instead of inheriting the ThingyObject class.
Yes, that's the Java way to do it. Surely we can do it better in Perl 6.
The problem with Java interfaces is that you have to rely on the library writer to have expected you to use an interface. Given the amount of CPAN modules that, for example, expect a glob and preclude me from passing in an IO::Handle with code like this:
croak "Need a glob" unless ref $thingie eq 'GLOB';
I'm not sure that the Java style is helpful. I'd rather not multiply entities needlessly.
For our "isa" operator, and (perhaps more importantly) for
multimethod dispatch and/or sub prototype checking, we only check if an
object inherits from a class's magic parent interface, and *don't* check
if it *really* inherits from that class itself.
<heretic> Why should an implementor inherit from the interface?
If inheritance and polymorphic equivalence are two different things, they ought to be handled two different ways. If anything, inheritance is a specific case of the general mechanism of marking polymorphic equivalence.
Again, the interesting question isn't "Does this thing derive from something I know about?" It's "Does this thing support the operations I expect it to support? I don't care how, just that it does."
I don't want to call $mock_foo->isa( 'foo' ) because $mock_foo *isn't* a foo. I don't want to call $delegates_to_foo->isa( 'foo' ) because $delegates_to_foo *isn't* a foo. They can both handle foo-methods, but neither is a foo.
</heretic>
-- c
