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