Re: What's up with %MY?
by Dave Mitchell other posts by this author
Sep 8 2001 1:08PM messages near this date
RE: Math functions? (Particularly transcendental ones)
|
Math functions? (Particularly transcendental ones)
"Bryan C. Warnock" <bwarnock@[...].com> wrote:
> On Thursday 06 September 2001 08:53 am, Dave Mitchell wrote:
> > But surely %MY:: allows you to access/manipulate variables that are in
> > scope, not just variables are defined in the current scope, ie
> >
> > my $x = 100;
> > {
> > print $MY::{'$x'};
> > }
> >
> > I would expect that to print 100, not 'undef'. Are your expectations
> > different?
>
> Yes. I would expect that to print 'undef'. '$x' doesn't exist as a key in
> %MY::
>
> >
> > I think any further discussion hinges on that.
>
> Yes. My expectations are different. My expectations are exactly like my
> previous PATH example.
>
> my $x = 100;
> {
> $MY::{'$x'} = 200; # Equivalent to 'my $x = 200'
> print $x;
> }
> print $x;
>
> That should print 200, and 100, should it not?
> You are creating a lexical in the current scope, and assigning it the value
> of 200. You are not finding a currently existing $x and assigning it the
> value of 200, resulting in 200 / 200.
>
> But let's be a little more pragmatic about it, shall we? Look beyond the
> fire and brimstone for a moment. As Dan said, we can already screw up your
> entire world. So other than a couple clever hacks from Damian, how will
> they be used?
I think you're confusing me with Ken Fox! At the moment, I'm just trying
to eke out of Damian what the precise semnatics of %MY:: will be, since
there are lots of possibilities. I'll join Ken in the Hellfire and Damnation
stakes after I've got a fixed target to aim at ;-)
Okay, personally I like the idea that %MY:: doesn't affect the values
or visibility (much) of outer scopes, since there's less
action-at-a-distance going on. The main drawback is that users may
find it counter-intuitive that you can't substitute $x in an expression
with %MY::{'$x'} and get the same result. But I guess they'll just
have to read the man page properly :-)
Anyway, in any particular scope, a variable $x can be in one of three states:
A) not defined, so '$x' refers to an outer lexical or global
B) defined but not introduced, and '$x' similarly refers to the outer value
(if any)
C) defined and introduced; '$x' refers to the local value.
Any manipulation of $::MY{'$x'} at compile or run time will have certain
effects in each of those 3 cases. Here's what I think all the permuations
should be.
... = %::MY{'$x'}
-----------------
A,B: returns undef; C: returns ref to $x.
In no case is $x autovivified.
%::MY{'$x'} = \...
-------------------
A@compile: equivalent of "my $x=..."
A@run: probably equivalent to "my $x=...", but we need to decide if affects
the visibility of previously compiled references to $x:
$x = 1; # package var
sub f { caller().{MY}{'$x'} = 2 if $_[0] }
sub g {
f(1);
$x; # does this see the lexical or the package var?
}
B,C: sets the lexical '$x' to the new value
delete %MY::{'$x'}
------------------
A,B: NOOP
C: marks the lexical as deleted. Any subsequent "...=$x" or "$x=..."
give a runtime error; subsequent "...=%MY::{'$x'} returns undef, while
a subsequent "%MY::{'$x'}=..." resurrects the variable with a new value.
|
