Paul Hodges writes:
> Luke Palmer:
> > Something likely more like:
> >
> > my role property_wrap[Property [EMAIL PROTECTED] {
> > method STORE($newval) { SUPER::STORE($newval but [EMAIL PROTECTED]) }
> > }
> > @bar but= property_wrap[false, foo];
>
> ...square brackets?
> ...roles can have methods? duh, they'd have to....ok....
> ...but, *square* brackets???
Yeah. Classes use square brackets when they're parametric, so I could
only assume roles do, too. That is, if you haven't seen this before:
class RingBuffer[$size, Class ?$of = Any] {
has @.buffer of $of is dim($size);
has ($.front, $.back, $.fill);
method push($elem of $of) returns Void {
@.buffer[$.back++] = $elem;
$.back %= $size;
$.fill++;
}
method shift() returns $of {
if $.fill <= 0 { throw X::BufferEmpty } # predeclared
return @.buffer[$.front++];
LAST { $.front %= $size }
}
}
I do have one question for the almighty gods, however. Can you
explicitly use the :: sigil to make a lexical parametric class, as in:
class RingBuffer[$size, ?::of = Any] {
has of @.buffer;
}
Well, modulo the possible ambiguity of the keyword of. Perhaps ::of
would have to be there, too...?
> And C< but [EMAIL PROTECTED] > looks like "but" is distributive.
> I think that's good, but not what I inferred from your last note on the
> topic.
I didn't say anything about C<but> not distributing over its I<right>
argument :-) It does, after all, make sense, as you'd probably not be
allowed to mark a property with the @ sigil.
> > As for just declaring it, um... why would you want to do that?
> > I could see making the array default to some value with a trait,
> > which is trivially:
> >
> > my @bar is default(undef but foo);
> >
> > But automatically marking every value that ever goes into the
> > array... I don't see the utility.
[snip]
> Usually I end up keeping track of some feature by putting all things
> with this feature into THIS array and all things like that into THAT
> array or some such parallel silliness. It works, and is faster than
> practically any object code on our poor old nag of a workhorse server,
> but then if I have to know which stack something came from when I send
> it to a sub I have to include another argument. There are LOTS of
> alternate ways to mark things, but I like this one.
Oh, okay.
And declarative is usually much nicer to read than procedural, so that
makes sense.
As far as I can tell, it's not possible without building some machinery
yourself, like we did above. That's okay though: we should be expected
to program generic solutions every once in awhile.
> > > But I'm not sure C<$r >>but=<< (false,foo)> works, and I really
> > > wanted to figure out a way to do it all in the declaration. Maybe
> > > it could be
> > >
> > > my @bar of Baz will do STORE.wrap { call >>but=<< (false,foo); }
> >
> > Yeah, that's definitely not right. C<will> works as follows:
> >
> > :w <declaration> will <identifier> <block>
> >
> > It's really just a shorthand for C<is>, so you don't have to put
> > parens around the block.
>
> But subs in A6 have a "will do", though I presume the do is optional?
You can leave out the C<do> if you like, but you also have to leave out
the C<will> in that case. For instance:
sub foo() { ... }
Is short for:
sub foo() will do { ... }
Which is in turn short for:
sub foo() is do({ ... })
Er, for some definition of 'short' :-)
> Hmm....still aware that this isn't a sub declaration,
>
> my @bar of Baz will init {
> .STORE.wrap { call >>but=<< (false,foo); }
> }
>
> I still like the idea that call could set itself up as an lvalue.
> ~smirk~
>
> So is it possible that this is a valid way to declare a container with
> modified methods all at once?
It would seem so. It's not a particularly clean one (even though it may
be clean *looking*). You might be able to do some jazz like this:
my Baz @bar but property {
method STORE($elem) { call($elem but (false, foo)) }
}
Where you're applying an anonymous property.
Luke
