develooper Front page | perl.perl6.language | Postings from January 2004

Re: Roles and Mix-ins?

Thread Previous | Thread Next
From:
Joe Gottman
Date:
January 6, 2004 20:08
Subject:
Re: Roles and Mix-ins?
Message ID:
005f01c3d4d4$17304320$42404a18@carolina.rr.com

----- Original Message ----- 
From: "Luke Palmer" <fibonaci@babylonia.flatirons.org>
To: "Joe Gottman" <jgottman@carolina.rr.com>
Cc: "Perl6" <perl6-language@perl.org>
Sent: Tuesday, January 06, 2004 9:34 PM
Subject: [perl] Re: Roles and Mix-ins?


> Joe Gottman writes:
> >
> > ----- Original Message ----- 
> > From: "Luke Palmer" <fibonaci@babylonia.flatirons.org>
> > To: <perl6-language@perl.org>
> > Sent: Tuesday, January 06, 2004 4:51 AM
> > Subject: [perl] Re: Roles and Mix-ins?
> >
> >
> > > David Storrs writes:
> > > >
> > > > On Sat, Dec 13, 2003 at 11:12:31AM -0800, Larry Wall wrote:
> > > > > On Sat, Dec 13, 2003 at 04:57:17AM -0700, Luke Palmer wrote:
> > > >
> > > > > : For one, one role's methods don't silently override another's.
> > Instead,
> > > > > : you get, er, role conflict and you have to disambiguate
yourself.
> > > >
> > > > How do you disambiguate?
> > >
> > > Let's see...
> > >
> > >     role Dog {
> > >         method bark() { print "Ruff!" }
> > >     }
> > >     role Tree {
> > >         method bark() { print "Rough!" }
> > >     }
> > >     class Trog
> > >       does Dog does Tree {
> > >         method bark() { .Dog::bark() }
> > >       }
> > >     }
> > >
> > > Perhaps something like that.  In any case, you do it by putting the
> > > offending method directly in the aggregating class.
> > >
> >
> >    How about something like
> >         class Trog
> >        does Dog {bark=>dogBark} does Tree {bark=>treeBark}
> >        {...}
> >
> >     Then we could have code like
> >       my Trog $foo = Trog.new();
> >       my Dog $spot :=  $foo;
> >       my Tree $willow := $foo;
> >       $spot.bark(); # calls dogBark()
> >       $willow.bark(); #calls treeBark()
> >
> >    This works better when Dog::bark and Tree::bark are both needed but
they
> > do different things.
>
> Renaming methods defeats the purpose of roles.  Roles are like
> interfaces inside-out.  They guarantee a set of methods -- an interface
> -- except they provide the implementation to (in terms of other,
> required methods).  Renaming the method destroys the interface
> compatibility.
>
> Your renaming can be done easily enough, and more clearly (IMO) with:
>
>     class Trog
>       does Dog does Tree {
>         method bark() { ... }   # Explicitly remove the provided method
>         method dogBark()  { .Dog::bark() }
>         method treeBark() { .Tree::bark() }
>     }

   But won't explicitly removing bark() from the class also disable
Dog::bark() and Tree::bark() for the class?  Renaming would work if other
methods in Dog are directed to dogBark() when they call bark(), and other
methods in Tree are redirected to treeBark().

Joe Gottman




Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About