> From: Luke Palmer [mailto:[EMAIL PROTECTED] > Hodges, Paul writes: > > > > sub setvals ($o, [EMAIL PROTECTED]) { > > $o but= $_; > > $o.$_ = true; > > } > > Y'all seem to be missing a C<for> somewhere :-) > > sub setvals ($o, [EMAIL PROTECTED]) { > $o but= $_ for @t; > }
LOL!!! I can't believe I missed that! =o) You're obviously right, tho. > I think that should work, as the right side of C<but> should > always be a property, so a property reference ought be interpreted correctly. > > > One thing, though.... could I do this? >=o} > > > > my property (foo,bar,baz) ^is true; > > $thingy ^but= (foo,baz); > > No, but you might be able to if you used proper vectorizing syntax ;-) > > my property (foo,bar,baz) is sometrait; # is automatically distributes > $thingy Âbut=Â (foo,baz); Didn't know "is" would do that. Good to know! And in my meager defense, I did reference MikeL's operator synopsis as of 3/25/03, which said ^[op] might be a synonym for <<>> or >><< (Sorry, no fancy chars here. :) > C<true> doesn't seem like a trait you would put on a property. C<true> > is a run-time property, and I think it would be awfully confusing to > make it a trait as well. If you're talking about some kind of > initialization, you might use: > > my property (foo,bar,baz) is first(1); > > Or C<is> might be correct if you're -- somehow -- deriving these > properties from the C<true> property. But I don't think that was the > intent. Was just initializing. Don't remember "is first(whatever)", though it seems a bit familiar. > > I'm pretty sure that syntax is way wonky -- would "is" be a > > vectorizable operator? Does it even qualify as an operator at all? > > C<is> is definitely an operator, much in the same way C<my> is an > operator. Whether it's vectorizable is questionable, because in all > cases I've seen the vectorization is implicit. That is, if it has a > non-vector meaning, the meaning of: > > my ($a,$b,$c) is foo; > > is a little fuzzy. What's C<is> applying to if it's not > applying to all of $a, $b, and $c? I hadn't seen it done that way...at least not recently enough that I remembered it. Last I recall, someone was thinking it would be my ($a is foo, $b is foo, $c is foo); Which really sux. I'm glad that was cleaned up. > > > > then write allow() to build roles for each value passed in, > > > > maybe taking an arg to say whether they should be truly global, > > > > or built in the caller's namespace.... > > > > > > Isn't that what my, our, Exporter, and the globalifying * are > > > all about? > > > > Probably, though I haven't seen anything yet about how the > > P6 version of the Exporter is going to handle things like specifying > > exportation of my() vars &co. > > I'm pretty sure that the interface to Exporter can be cleaned > up quite a bit in Perl 6. For now, though, I think it's fine to assume it works > exactly like Perl 5's. Which is why I was building an allow(), which would let you specify property names to create in the use() statement of the module. I have *NO* clue how you would use the current Exporter to create roles on-the-fly, but I think I could build something that would do its own exporting to whatever level it was told. Maybe level 0 is make them but don't export, 1 is export them into the calling namespace, and 2 is truly global: use MyRoles export => 0, <<foodiddly podunk whatever_other_silliness_is_on_the_menu_today>>; my $whatsit but= MyRoles.foodiddly; # above line made this acceptable $whatsit.foodiddly = 1; but could I instead say my $whatsit but= MyRoles.foodiddly(1); or something like that? ***** "The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers.61"
