in reply to Iterating & Playing with Caller's Pads

A conversation regarding user-perl hidden lexicals popped up in the chatterbox recently. There was a thought that if you prepend the variable name with '&' then it is effectively inaccessible from user-side perl. The rest of the conversatin wasn't relevant but that's still an interesting idea. I still don't understand internals well enough to know what happens to PADLISTs on entering/leaving a lexical scope but hey...

Or... on further consideration now that you're potentially stomping on other people's lexicals I would think that your variable key should also incorporate some disambiguation between individual instances of yourself - consider including your own address in the variable name so if the user starts two iterators then both don't write on each other. Obviously this raises other concerns about circular references - your iterators are now responsible for cleaning up every CV context you've been in on iterator destruction (looks like you should turn that into an object now).

  • Comment on Re: Iterating & Playing with Caller's Pads

Replies are listed 'Best First'.
Re: Re: Iterating & Playing with Caller's Pads
by shotgunefx (Parson) on Sep 27, 2002 at 13:59 UTC
    My thinking on the lexical naming of the var that is hidden in the scope would be a \w friendly mangling of the function and it's args. That way you could have multiple calls in the same scope.

    Just to clarify, because my example did not is that I'm interested in Lazy Iterating.

    -Lee

    "To be civilized is to deny one's nature."
[reply]

      And if your function is called with the same arguments in a different instance? You can use line number to disambiguate between instances that aren't on the same line but I'm not sure how you keep track of different instances with the same arguments on the same line. Unless... keep track of the specific instances of your arguments - pointers perhaps. Those are only four bytes (on my platform anyway) and would be cheap to keep track of. If you do this I'd like to see the code.

[reply]

        So how does something for for (@array) { ... } keep track of it's state? Somehow *that* knows where it is. I recall that the hash accessors values/keys alter the hash but the list operators don't appear to do that (I just ran perl -MDevel::Peek -e "@a = qw(hello make my sheep into cherries); for (@a) { Dump(\@a)" to demonstrate to myself that for() doesn't alter the the array anyway. Oh yeah, and these operators also work on lists which don't even have an AV construct so duh, yeah I guess that makes sense. (smacks forehead)

        I guess all I can think of is that while(scalar ..) and related's actual OP tracks that. I think what you want to do is use B::Generate to get a handle to a current opcode and then hang the list state off that somewhere... (not that I know if that's even possible, I'm just thinking about this as I type this).

[reply]
[d/l]
[select]
        For the elements example (grab a chunk of array non-destructively) this to me, would be "do what I mean" if it was called in the same scope.

        -Lee

        "To be civilized is to deny one's nature."
[reply]

In Section Seekers of Perl Wisdom