Larry Wall writes:
>
> I think it's also a mistake to give C<my> two unrelated meanings.
> These are not lexically-scoped variables any more than "our"
> variables are, and the fact that they can happen accidentally in
> Perl 5 as persistent lexically scoped variables is, er, accidental.
> They are lexically scoped aliases to properties of the current block.
> Perhaps we should just go with that:
>
> property $foo = 0;
>
in this example
sub a {
state $x ;
my $y ;
my sub b { ... } ;
...
}
how "my sub b" is different from "state $x" from the point of view of
scope ?
when scope of "sub a" is left, $y variable is notifyed about it --
its value is lost .
is "sub b" somehow notifyed when scope of "sub a" is left. ???
I mean , for example , that one of its ( sub b ) BIGLETTER block can
fire and change its ( sub b ) state variables. Is there some crucial
difference between scope of $y and &b ?
in other words,
what is a difference between where $x , $y and &b lives .
and how these places behave dynamically -- when lexical scope is
entered or left. ???
>
> But my gut feeling says if it's scoped differently, it had better
> have a different introducer. Scope is too important a distinction
> to relegate to a trait of the variable, even though it may be one
> from a metadata point of view. Particularly since we may want it
> to warp that assignment notation into an INIT {} or some such.
>
> Actually has/have is kinda cute:
>
> Each object has...
> We all have...
>
do I understand correctly , that "has" introduce a block property that
is used by "new"-like methods ??? or it is a property of class that
"posess" that block. ???
actually , the same question about "state" - does it introduce the
property of an enclosing block or a property of a sub "posessing" that
block -- or am confused and these two things are the same ???
> where "we all" could be taken to mean either "all objects" or "all
> invocations of this block". We could use this for class attributes
> and they wouldn't show up globally. On the other hand the class's
> class object isn't quite the same thing as the class's init block.
> But we wouldn't have to tell people that...
>
> Whatever. Important thing is that it has to be out front if it's
> a different scope, even if it's not as important a scope as "my".
>
> When you think about it, that's why we have brought "method",
> "submethod", "multi", etc. out front too. These are just scoping
> distinctions important to the dispatcher. But it's important to
> human understanding to see that at the beginning. Submethods aren't
> as important as either subs or methods, but it would be a mistake to
> make submethodism a mere property of either methods or subs.
>
> In the same way, I think it's a mistake to see a block attribute as
> either "our" or "my".
>
> Just don't anyone suggest "submy"...
do you mean here a variable that is seen only in the current lexical
scope but invisible in any of inner lexical scopes. ??? ( or this was
just a joke ?...)
thanks,
arcadi
