Jonathan Scott Duff writes: > On Thu, Dec 04, 2003 at 05:57:52PM -0700, Luke Palmer wrote: > > Hodges, Paul writes: > > > I'd *like* to be able to predeclare a trait or property to be distributed > > > across any values placed in this array, but only this array. For example, it > > > would be nice if I could have the default aspects of false and foo be > > > applied to any Baz that gets stuck into @bar, but obviously this isn't the > > > syntax to do it. I could make Baz's new() do it, but I don't want *ALL* Baz > > > objects to be false and foo...just the ones in @bar. So, what I need is > > > something more like > > > > > > my @bar of Baz; > > > @bar.STORE.wrap { my $r = call; return $r >>but=<< (false,foo); } > > > > 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]; > > > > With emphasis on "something". (Extrapolating wildly the little bit I > > know about roles and making up some semantics, such as C<but [EMAIL PROTECTED]>). > > What's the difference between what you have above and this: > > my property property_wrap (Property [EMAIL PROTECTED]) { > method STORE($newval) { SUPER::STORE($newval but [EMAIL PROTECTED]) } > } > @bar but= property_wrap(false, foo); > > ? The examples I remember from the As and Es all have round brackets > around trait parameters (Hmm. And I can only remember is-trait examples > too). Granted, the universe could have shifted under my feet without my > knowledge.
No, it was just a braino on my part. I forgot that I've already seen parametric properties in a lot of places... :-/ > I discovered after reading this email that I've been assuming that > square-bracket parameterization happened at compile-time while > round-bracket parameterization was, of course, run-time. I don't know > if that's even partially true though. If that isn't the distinction, > then what is? Why the two bracket styles? It's a manifestation of "different things should look different". If classes look too much like subroutines, things would get confusing and hard to read. I don't think it's necessarily a compile-time thing, as one would expect this to work: class Foo[Int $param] {...} sub make_foo(Int $param) { Foo[$param].new; } I wonder if we'll have C++-like template specialization... I'd like that, especially since Perl would keep from inventing a new language in the process. multi class PrintBasic[Class $of] { method go() { print "Non-basic"; } } multi class PrintBasic[Int|Num|Str] { # Can I do that? method go() { print "Basic"; } } Hmm. Luke > -Scott > -- > Jonathan Scott Duff > [EMAIL PROTECTED]