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]
