easier duck typing in .can
Yuval Kogman
.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 <nothi...@woobling.org>
http://nothingmuch.woobling.org 0xEBD27418
Sam Vilain
> Since CANDO is a multimethod, IMHO this can be safely extended to
> allow:
>
> $object.can(Class);
> $object.can(Role);
>
> to better support duck typing.
>
Why would you not use .does or .isa there? Are you wanting this to go
through all of the Class/Role's methods and check that the $object.can()
them?
I think that perhaps .can($Method) (where $Method.isa(Meta::Method))
would be acceptable, then .can(Role) can either be defined to be
.can(all(Role.get_methods)), or we just leave the user to use that
snippet - after all, such extreme duck typing is expensive and shouldn't
be huffmanised overly IMHO. We want people to use the Role objects
unless they have a really good reason, and besides you can always just
wrap things up in a Facade if you have to.
Sam.
Yuval Kogman
> Why would you not use .does or .isa there? Are you wanting this
> to go through all of the Class/Role's methods and check that the
> $object.can() them?
Because if you don't control $object's class you can't change it.