Re: Roles as anonymous and/or closures
Juerd writes:
> (And write classes ucfirst, please)
>
> > return $self but role {
>
> does role { ... }
Nope, Aaron was right here, since you're not trying to mutate $self;
you're just trying to return a new $self with other capabilities.
> > It certainly seems very attractive, but I'm not sure if roles can be
> > anonymous and/or closures.
>
> They can. But I think what you wrote is rather unnecessarily complex.
Perhaps for this case, but I could see situations where this technique
could be valuable.
Luke
Re: Roles as anonymous and/or closures
On Tue, 2005-04-26 at 09:49, Juerd wrote:
> > return $self but role {
>
> does role { ... }
As I understood (please correct me if I'm wrong), the difference between
"does" and "but" was that does modifies the existing object in-place,
and does creates a copy with the new mixin functionality. In this case,
the method in question is acting as a generator, and should NOT modify
the invocant.
I'm getting this from S12:
Then you can say
$a = 0 but answer(42)
Note that the parenthesized form is not a subroutine or method
call. It's just special initializing syntax for roles that
contain a single property. The above really means something
like:
$a = ($anonymous = 0) does answer(42);
which really means:
(($anonymous = 0) does answer).answer = 42;
$a = $anonymous;
Which is why there's a but operator.
> > It certainly seems very attractive, but I'm not sure if roles can be
> > anonymous and/or closures.
>
> They can. But I think what you wrote is rather unnecessarily complex.
How is this complex? This is fairly standard for a factory type method
(I think I said "generator" before, oops), but in most languages, a
factory either has to return from a pre-defined tree of classes, or has
to build its own mechanism. In Perl 6, closures combined with anonymous
roles let us build this functionality trivially, on the fly.
--
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback
Re: Roles as anonymous and/or closures
On Tue, 26 Apr 2005, Aaron Sherman wrote:
It also might be useful for roles to be able to delete members and
methods from a class like so:
role foo {
has $.x;
has not $.y;
}
But that brings up the issue of who has the final authority. In class
composition, a method defined in the class hides those in the roles, and
in this sense it is the boss on "adding decisions". I like this a lot
because I think it makes it possible for me to read a class description
and have a sense of what is going on. With the "has not" proposal, it
seems that the role would need to be the boss on "deleting decisions".
Could get pretty confusing!
--abhijit
Abhijit Mahabal http://www.cs.indiana.edu/~amahabal/
Re: Roles as anonymous and/or closures
All IIRC/AFAIK:
Aaron Sherman skribis 2005-04-26 9:25 (-0400):
> method make ($self: $make, [EMAIL PROTECTED]) returns(car) {
returns car;
(And write classes ucfirst, please)
> return $self but role {
does role { ... }
> It certainly seems very attractive, but I'm not sure if roles can be
> anonymous and/or closures.
They can. But I think what you wrote is rather unnecessarily complex.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Roles as anonymous and/or closures
Is any of this legal?
class car {
...
method make ($self: $make, [EMAIL PROTECTED]) returns(car) {
return $self but role {
has $.make = $make;
method model($self: $model) returns(car) {
unless $model eq any(@models) {
die "Invalid model: $model";
}
return $self but role {
has $.model = $model;
}
}
}
}
}
my car $generic .= new;
my car $ford = $generic.make("ford",);
my car $pinto = $ford.model("pinto");
It certainly seems very attractive, but I'm not sure if roles can be
anonymous and/or closures.
If we can do this, then it brings up the possibility of currying
mixin-generator methods and all sorts of other useful features which
would greatly simplify some very complex classes.
It also might be useful for roles to be able to delete members and
methods from a class like so:
role foo {
has $.x;
has not $.y;
}
This allows a role to "reset" the application of subordinate roles (as
the example method, make, might want to reset the application of its own
"model" method's anon role).
"has not" precludes ever having a type named "not", and if that's a
problem it could read "not has" or "!has", but that feels a bit klunkier
to me.
--
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback
