In a message dated Fri, 13 Oct 2006, Jonathan Lang writes:
Since Baz does both Foo and Bar, you cannot use type-checking to
resolve this dilemma.
Why not? Why shouldn't this work:
my Foo $obj1 = getBaz(); # object is a Baz
$obj1.baz(); # Foo::baz is called
my Bar $obj2 = getBaz(); # object is a Baz
$obj2.baz(); # Bar::baz is called
my Baz $obj3 = getBaz(); # object is a Baz
$obj3.baz(); # Depends on Bob's implementation of ::Baz
All three objects happen to be Baz's, yes. But the client code doesn't
see them that way; the first snippet wants a Foo, the second wants a Bar.
They should get what they expect, or Baz can't be said to "do" either.
If methods are entirely dispatched *by name* ("duck typing"), then I
agree, we have a problem. But Perl 6 supposedly supports a) multiple
inheritance, b) multiple dispatch, c) traits, and d) DBC. I believe the
union of those requirements means that methods must be dispatched in a
more sophisticated way than just looking for a matching name.
(I know a guy who works in building maintenance and also does moonlighting
as a computer tech. In either of his two roles, he could be said to "do
windows". But what windows he does when someone asks him to do windows is
disambiguated by his current role.)
The way things are now, it would appear that Bob's stuck. Short of
rewriting one of ( Foo and foo ) or ( Bar and bar ) to use a different
method name in place of baz, he can do nothing to resolve the
syntactic collision between Foo and Bar while continuing to let foo
and bar run properly.
Duck-typing would give you this dilemma, no question about it. But I
think Perl 6 is beyond duck-typing.
The dilemma only arises in the context of calling .baz on a *Baz*--and Bob
hasn't written the class Baz yet. The question remaining is just one of
disambiguation syntax and/or what happens when Bob chooses to do nothing
about disambiguation (compile-, compose- or instantiation-time error, or
some arbitrary default dispatch?).
Trey
--
Thoughts?
--
