develooper Front page | perl.perl5.porters | Postings from March 2006

Re: how should %^H work with lexical pramas

Thread Previous | Thread Next
Nicholas Clark
March 29, 2006 05:07
Re: how should %^H work with lexical pramas
Message ID:
On Wed, Mar 29, 2006 at 02:09:44PM +0200, Rafael Garcia-Suarez wrote:

> A concrete example should help; let's say you want to write a pragma
> foo, providing a function foo::do_that() that does different things
> depending on whether the 'use foo' pragma is in effect in the current
> lexical scope. Then, in the body of do_that(), you'll need to test what
> the value of $^H{foo} was at compile-time in the caller's scope.

And given that you might want to implement your pragma with more than one
level of subroutine, I infer that you might need to get at $^{foo} from
somewhere up your caller's scope. This starts to sound like the correct
hash should be returned as another value from caller.

> Then, maybe the solution is, as you said, to have a duplicate of %^H
> that is populated with values from %^H during compilation, and which is
> accessible at run-time (probably read-only, but it's better to avoid
> that if possible.) What's absolutely needed, though, is to store them in
> the most compact way possible. So a linked list of HE (pointed to by
> cops) can be a solution, so when you enter a new scope where a new value
> is added to %^H you only need to add it in front of the linked list. (If
> you have several values, including undef, in the linked list, the first
> one wins.) Access time is less important here.

I was thinking, if at runtime you change the caller's %^H, should that change
be reflected in any subsequent string eval they perform? If so, this would
mean that eval should be getting its (local compile time) %^H from the
current scope's run time %^H-a-like. (The %^H result from caller(-1), not
that caller(-1) is legal)

Nicholas Clark

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About