Synopsis 12 specifies that:
.can interrogates any class package's CANDO multimethod for
names that are to be considered autoloadable methods in the
class
but aside from that is just a name -> method iterator mapping.
Since CANDO is a multimethod, IMHO this can be safely extended to
allow:
$object.can(Class);
$object.can(Role);
to better support duck typing.
Scenarios in which this is useful are when you are mixing classes.
For example, CGI::Cookie and CGI::Simple::Cookie (perl 5 land) have
the same interface but don't strictly know about each other.
If you want to allow drop-in replacements to some objects then you
typically would rather check for duck typing than role consumption.
A real life example is CGI::Cookie::Splitter, which really doesn't
care (and for good reasons shouldn't care) what the object it's
dissecting is, as long as it follows the CGI::Cookie interface.
However, since it's not tied to the CGI::Cookie implementation in
any way except that CGI::Cookie was the first module to provide that
interface, it shouldn't require it.
Sometimes in the real world roles or base classes are not as
refactored as they should be, and if CGI::Simple::Cookie was given
the option of 'doing' CGI::Cookie but getting a headache out of it
because CGI::Cookie didn't have foresight to be easily 'done', that
shouldn't harm people.
Anyway, i'm reiterating why duck typing is good, and everyone
probably knows this already.
A complementing solution to better support duck type is from the
perspective of e.g. CGI::Simple::Cookie in my example:
http://search.cpan.org/perldoc?asa
This could be somewhat mirrorred as:
class Foo {
can Bar; # claim that you can do it, and if possible also
# get compile time verification
}
without affecting our hard earned renewed purity of .isa and .does
(due to roles in Perl 6).
Comments?
--
Yuval Kogman <[EMAIL PROTECTED]>
http://nothingmuch.woobling.org 0xEBD27418
pgpDjfA2jPh0W.pgp
Description: PGP signature
