Re: easier duck typing in .can

2006-06-18 Thread Sam Vilain 

Yuval Kogman wrote:

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.

Re: easier duck typing in .can

2006-06-18 Thread Yuval Kogman 
On Sun, Jun 18, 2006 at 18:08:00 +1200, Sam Vilain wrote:

 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.

-- 
  Yuval Kogman [EMAIL PROTECTED]
http://nothingmuch.woobling.org  0xEBD27418



pgpLRbF8bTTrd.pgp
Description: PGP signature

easier duck typing in .can

2006-06-17 Thread Yuval Kogman 
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



pgpuJ14rwywVH.pgp
Description: PGP signature