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