Austin Hastings wrote:
role Dog {must bark();}
role Tree {must bark();}
class crossPerson {
method bark() {speak_sharply;}
}
class Trog does Tree does Dog {
method bark() {bark_like_a_trog;}
}
multi sub purchase(Dog $mansBestFriend) {...}
multi sub purchase(Tree $shrubbe
On Thu, 2004-01-08 at 16:24, Jonathan Lang wrote:
> In this example, there's no difference between the Dog and Tree roles;
> however, this would almost certainly not be the case most of the time - at
> the very least, a class with a Dog role would have @.legs, while a class
> with the Tree role wo
Austin Hastings wrote:
> Jonathan Lang wrote:
> > Austin Hastings wrote:
> > > This kind of granularity does kind of imply a JavaScript-like
> > > ability to compose objects, too, no? (If you can compose
> > > requirements atomically, why not compose capabilities, too?)
> > >
> > > my $photon do
From: chromatic [mailto:[EMAIL PROTECTED]
> On Wed, 2004-01-07 at 00:43, Jonathan Lang wrote:
> > Maybe as an alternative to
> >
> >role Stringify {must stringify();}
> >sub print_it (Stringify $thingie) {print $thingie.stringify();}
> >
> > you might be able to say
> >
> >sub print_it
Jonathan Lang [mailto:[EMAIL PROTECTED] wrote:
> Austin Hastings wrote:
> > Indeed. I like the idea of dynamic anonymous roles -- it's more
> > behavioral than anything else.
> >
> > sub print_it ($thingie must stringify()) {...}
> >
> > Definitely gets down to the lowest level quickly, which is
On Wed, 2004-01-07 at 00:43, Jonathan Lang wrote:
> Maybe as an alternative to
>
>role Stringify {must stringify();}
>sub print_it (Stringify $thingie) {print $thingie.stringify();}
>
> you might be able to say
>
>sub print_it ($thingie must stringify()) {print $thingie.stringify()
Austin Hastings wrote:
> Jonathan Lang wrote:
> > Maybe as an alternative to
> >
> >role Stringify {must stringify();}
> >sub print_it (Stringify $thingie) {print $thingie.stringify();}
> >
> > you might be able to say
> >
> >sub print_it ($thingie must stringify()) {
> > print $t
From: Jonathan Lang [mailto:[EMAIL PROTECTED]
> Piers Cawley wrote:
> > > Why does it have to be a String, though? What prevents it from
> > > working with anything that can stringify, besides the overly
> > > restrictive signature? What if you could say (the Perl 6 equivalent
> > > of):
> > >
From: chromatic [mailto:[EMAIL PROTECTED]
> On Tue, 2004-01-06 at 22:26, Austin Hastings wrote:
> > So on the grand balance of utility, what are the metrics that traits are
> > supposed to help improve?
>
> Two big ones:
>
> - naming collections of behavior that are too fine-grained
> to fi
Piers Cawley wrote:
> > Why does it have to be a String, though? What prevents it from
> > working with anything that can stringify, besides the overly
> > restrictive signature? What if you could say (the Perl 6 equivalent
> > of):
> >
> > sub print_it ( does Stringify $thingie )
> >
chromatic <[EMAIL PROTECTED]> writes:
> On Tue, 2004-01-06 at 22:26, Austin Hastings wrote:
>
>> So on the grand balance of utility, what are the metrics that traits are
>> supposed to help improve?
>
> Two big ones:
>
> - naming collections of behavior that are too fine-grained to fit into
On Tue, 2004-01-06 at 22:26, Austin Hastings wrote:
> So on the grand balance of utility, what are the metrics that traits are
> supposed to help improve?
Two big ones:
- naming collections of behavior that are too fine-grained to fit into
classes cleanly
- enabling finer-grained
12 matches
Mail list logo
