On Thu, 2004-05-06 at 11:24, Dan Sugalski wrote:
> Well... sort of, but only because you've defined that for perl 6
> classes automatically do themselves--you've conflated inheritance and
> interface. Which is fine, except that it falls down in the face of
> objects from classes that don't do that.
Given:
- class A, a superclass
- class AB, a subclass of A
- class Eh, a class that does A but does not inherit from it
- subroutine signature foo(A some_object)
If the signature checker checks isa, you can't pass in Eh, even though
its writer has guaranteed that its semantics match those of A.
If the signature checker checks does, you can pass in A, AB, or Eh,
assuming that subclassing marks does on the subclass *or* that you fall
back to checking isa if does fails.
Either will probably work, but you and I both agree there's a problem in
that does and isa overlap somewhat. We disagree on the implications of
that overlap, though.
Both can answer the question "can this object handle this method?" isa
goes further, though, telling you where to look for the method if it's
not part of the class itself.
That's why I'm not sure making isa the base operation is the right
behavior. If you put does alongside it, you have two mechanisms by
which people can answer the same question -- not only is that kind of a
waste, but people will do that incorrectly. If you put does atop isa,
you're getting less specific and throwing out information.
If you make does the base operation, you can be more specific with isa
(or delegates or aggregates, if you want to be that specific) by
separating the method lookup part.
As a plus, languages that don't care about does don't have to do expose
it. I can't see a place where it falls down -- but if some Perl 6 code
asks a does question about a Ruby object, it just works.
-- c
