--- Luke Palmer <[EMAIL PROTECTED]> wrote:
> Hodges, Paul writes:
> > How about
> >
> > use Baz; # assume object type
> > my property foo;
> > my @bar of Baz is false but foo; # maybe not what you meant?
>
> Definitely not what you meant. Fortunately, the compiler will teach
> you a thing or two about it: C<false> is not a trait.
Duh. I knew I'd do something simple/stupid like that. :)
But you get the idea.
> But indeed foo would apply to @bar itself, rather then to any element
> that goes into @bar later.
>
> > If you apply a trait like false to an array, I expect it to apply
> to the
> > "array instance object" itself and not the content, so that
> > push @bar, Baz.new();
> > if @bar { print "stuff"; } else { print "empty"; }
> > if @bar[0] { print " oops"; } else { print " ok"; }
> > would print "empty oops" instead of "stuff ok".
> >
> > 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];
...square brackets?
...roles can have methods? duh, they'd have to....ok....
...but, *square* brackets???
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.
> With emphasis on "something". (Extrapolating wildly the little bit I
> know about roles and making up some semantics, such as C<but
> [EMAIL PROTECTED]>).
lol -- oh, ok. :)
But it's *good* BS.
> 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.
Nothing that couldn't be done in a dozen other ways, but this is one
way that I like. It's perhaps a slightly contrived situation, but one I
hope might shed some light on the semantics so that I can learn to use
them when they're a better solution that the kludges I so often end up
with.
In other words, there's always the possibility of doing it another way.
Any object-oriented code functionality could be replicated by purely
functional code, but sometimes you'd end up having to design entire
paradigms to replace some of the functionalities. It's just a mindset
issue, though I will readily confess that my mind is usually set at
wierd angles.
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.
> > 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?
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?
__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
