On Thu, May 06, 2004 at 01:52:45PM -0400, Dan Sugalski wrote: : At 10:44 AM -0700 5/6/04, chromatic wrote: : >On Thu, 2004-05-06 at 10:39, Aaron Sherman wrote: : > : >> The simple case is: : >> : >> sub foo(X $i is rw) {...} : >> class X {...} : >> class Y {...} : >> my Y $var = 'something'; : >> foo($var); : >> : >> In this case, something kind of interesting has to happen. : >> : >> Either the signature checking has to verify that Y isa X (and thus can : >> be used polymorphically as X, not just converted to X) ... : > : >I'd argue 'Y does X', actually, though Dan disagrees and says "Well, : >whatever!" : : Nope. Dan says "Is that X in the signature an assertion of interface : or of parentage?" and has the Perl 6 compiler emit the appropriate : code. (Parentage is the safer option generally, since only in perl 6 : is the class == interface assertion going to be true, and you might : want to be able to yank in Python/Ruby/Perl5/Objective-C/Java/C#/C++ : objects and classes. Or... you might not, which is fine too)
I don't see a problem with using "does" sematics in Perl 6 because roles and classes live in the same namespace, and "does" naturally devolves to "isa" semantics if you hand it a class.
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.
We can't devolve to isa checking under the hood, because there are cases where a class can assert that it has a role without pulling in the role externally. (Storable, for example, will be a likely thing here as classes assert they do Storable without pulling in an external Storable role, since a generic Storable's generically useless) So there will be classes that have a role in them without having a class of the same name in their inheritance hierarchy anywhere.
Does, though, can only check the assertions of whether a class does the role in question--it can't check inheritance, because while Perl 6 makes roles and classes more or less the same (kinda sorta) that's not true of other languages. If I have an Objective-C or Java object of class Foo, and Foo implements the Bar interface, then that object does(Bar) while not being isa(Bar), and isa(Foo) without does(Foo). Ruby's mixins behave similarly.
In an all-Perl 6 environment it should work out OK if Perl 6's signature checking conflates isa and does (unless you're going to add a "doesn't" to class definitions :) but it's going to make things potentially interesting in a mixed-language environment which is reasonably likely.
Not, mind you, that it necessarily matters, but it's good to make sure things are clear (whether it's an isa or a does check) and it may be useful to have specific syntax if people want to be explicit whether they're checking isa or does. (Or can, I suppose, if you want to go that far)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
