At 12:50 PM 9/4/2001 -0500, Garrett Goebel wrote:
> > sub Bar::import {
> > my %m = caller(1).{MY}; # or whatever
> > delete %m{'$x'};
> > }
>
>hmm... when:
>
>{ my $x = 1; sub incr {$x++} }
>
>is compiled, the $x++ in &incr refers to the lexical $x. So deleting it
>would remove it from the scratchpad of &incr. But I would guess that
>future calls to &incr would have to autovify $x in the scratchpad and
>start incrementing it from 0. I.e., ignoring a package $x if it exists. I
>could see people prefering it either way...
Folks might also want that to then refer to the $x in the enclosing scope.
Don't think that's going to happen, though. (Lots and lots of runtime
overhead in that case)
> >
> > IE what effects to do the standard hash ops of adding, modifying,
> > deleting, testing for existence, testing for undefness, etc
> > etc map onto when applied to some sub's %MY, at either compile
> > or run time.
>
>I would hope that it would be identical to the current behavior we
>experience when modifying a package's stash. Or however the new behavior
>for stashes maps to Perl6.
I can see allowing read/write/change/iterate access (possibly enforcing
types when writing) but not delete. That opens up a number of cans of worms
I'd rather stay closed for now.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
