Re: Implicit Role Declarations (was Re: implicitly doing a role)
On 11/8/05, chromatic <[EMAIL PROTECTED]> wrote: > On Fri, 2005-11-04 at 13:15 -0500, Austin Frank wrote: > > > If roles are interfaces, do we want any class that provides an interface > > consistent with a role to implicitly do the role? That is, if a class > > fulfills all of the interface requirements of a role without actually > > saying it does the role, does it do the role anyway? > > After thinking about this a little more, I think there may be a bit of > misunderstanding about what I want here. > > Having a class implicitly *do* a role if it has methods and attributes > of the appropriate name is a bad idea -- there's too much room for > accidental collision there. > > Sure, people shiny-eyed about duck typing might reasonably say "Why? > That doesn't make sense!" but it's a careless duck typer who randomly > throws objects in collections and hopes for the best. You *can* > mistakenly use an object that quacks incorrectly and spend some time > debugging it, but if we're providing a system that can catch some of > that incorrectness, I don't see what benefit there is to subverting its > ability to detect incorrectness. > > What I want instead, and what might seem similar in the sense that it's > exactly the opposite, is implicit declaration of a role for each > explicitly declared class. > > That is, if I declare a Dog class, there immediately springs into being > a Dog role empty of everything but the expectation that whatever does > that role provides everything publicly accessible that an instance of > the Dog class does. In other words, a role is just a closed class and a class is just an open role? Larry stipulated this about a month ago. Rob
Implicit Role Declarations (was Re: implicitly doing a role)
On Fri, 2005-11-04 at 13:15 -0500, Austin Frank wrote: > If roles are interfaces, do we want any class that provides an interface > consistent with a role to implicitly do the role? That is, if a class > fulfills all of the interface requirements of a role without actually > saying it does the role, does it do the role anyway? After thinking about this a little more, I think there may be a bit of misunderstanding about what I want here. Having a class implicitly *do* a role if it has methods and attributes of the appropriate name is a bad idea -- there's too much room for accidental collision there. Sure, people shiny-eyed about duck typing might reasonably say "Why? That doesn't make sense!" but it's a careless duck typer who randomly throws objects in collections and hopes for the best. You *can* mistakenly use an object that quacks incorrectly and spend some time debugging it, but if we're providing a system that can catch some of that incorrectness, I don't see what benefit there is to subverting its ability to detect incorrectness. What I want instead, and what might seem similar in the sense that it's exactly the opposite, is implicit declaration of a role for each explicitly declared class. That is, if I declare a Dog class, there immediately springs into being a Dog role empty of everything but the expectation that whatever does that role provides everything publicly accessible that an instance of the Dog class does. You don't get the nice code-reuse of roles, but you can use your doglike object -- Mock Dog, Dog Proxy, Logged Dog, Decorated Dog -- anywhere you can use a Dog and everyone's happy. They're man's best friends, you know. -- c
Re: implicitly doing a role
On Fri, 2005-11-04 at 13:15 -0500, Austin Frank wrote:
> If roles are interfaces, do we want any class that provides an interface
> consistent with a role to implicitly do the role? That is, if a class
> fulfills all of the interface requirements of a role without actually
> saying it does the role, does it do the role anyway?
No.
role Dog
{
method bark { ... }
}
class Tree
{
has $.bark;
}
A role is a named collection of behavior and state, not just a list of
method and property names. The context is highly important. It's the
difference between homonyms and allomorphs.
-- c
Re: implicitly doing a role
On 11/4/05, Austin Frank <[EMAIL PROTECTED]> wrote:
> Hello!
>
> If roles are interfaces, do we want any class that provides an interface
> consistent with a role to implicitly do the role? That is, if a class
> fulfills all of the interface requirements of a role without actually
> saying it does the role, does it do the role anyway?
>
> role Documented {
> has $.documentation;
> }
>
> class Foo does Documented { ... }
>
> # I don't know why Bar isn't declared as doing Documented
> # but it meets all the requirements of doing Documented...
> class Bar {
> has $.documentation;
> }
>
> my $baz = Foo.new( $documentation => "q to quit" );
> my $qux = Bar.new( $documentation => "enter to continue" );
>
> sub show_docs ( $obj.does( Documented ) ) { # or $obj ~~ Documented
> say $obj.documentation;
> }
>
> show_docs( $baz ); # "q to quit"
> show_docs( $qux ); # "enter to continue" -or-
> # error because Bar doesn't explicitly do
> # Documented?
>
>
> I guess we don't really need implicit doing of roles to get both of
> those objects to print their documentation, as we could have something like
>
> sub show_docs ( $obj ) {
> if ( defined $obj.documentation ) {
> say $obj.documentation;
> }
> else {
> die "Should have included a documentation string"
> }
> }
>
>
> Should roles that are implicitly done pass tests like .does and ~~ ?
> What are the reasons that they should or shouldn't?
I say no. It goes back to does a role provide a list of function names
with possible default implementations or does it provide a behavior
that is supported by a set of related functions that one can override,
if desired. What you're proposing assumes that roles are nothing more
than jazzed up Java interfaces. I would hate to see that happen. So, I
say that it should be the latter.
Rob
