in reply to PadWalker's closed_over - but for our variables?

Does talking about "closing over" (aliases to) package variables even make sense? Isn't one of the properties of lexical variables being closed over that they can't be accessed from the outsidecaller, which isn't true for "global" package variables? (In other words, your code could just as well be sub { print "$my,$BLA::our" }.)

XY Problem? Or do you just want to get a list of all the variables that a coderef accesses?

Replies are listed 'Best First'.
Re^2: PadWalker's closed_over - but for our variables?
by LanX (Saint) on Apr 03, 2021 at 16:25 UTC
    our variables are lexical package variables.

    "Lexical" describes the scope not how they are stored (private vs package)

    The docs are confused here.

    > can't be accessed from the caller,

    one still needs to know the package of an our-variable to access it

    > Or do you just want to get a list of all the variables that a coderef accesses?

    I need to introspect a coderef for the package vars used inside, you are right that it might not matter if they were declared outside with our.

    As already mentioned: PadWalker offers peek_our but only usable from the inside.

    edit

    so I effectively need peek_sub for package vars

    Cheers Rolf
    (addicted to the Perl Programming Language :)
    Wikisyntax for the Monastery

[reply]
[d/l]
[select]
      our variables are lexical package variables. "Lexical" describes the scope not how they are stored (private vs package)

      I'm not sure I agree. At least in my mind, package variables are quite different from lexical variables: package variables are stored in the symbol table (and they can be inspected and manipulated there) and lexical variables in the pads (which aren't so easy to inspect, hence PadWalker). All that our does is create an alias to a package variable, that that alias happens to be lexical in scope is the only "lexical" thing about it, I think. Anyway:

      I need to introspect a coderef for the package vars used inside, you are right that it might not matter if they were declared outside with our.

      At the moment I'm not aware of an easy solution. Any general-purpose solution would fail in the presence of no strict, since I could write no strict; ${"${x}::${y}"} = "hello"; or even ${"a".int(rand(999))} and you'd never know which package variable I just accesed. Perhaps something PPI-based...? I don't have any other good ideas at the moment, perhaps inspiration will strike later.

[reply]
[d/l]
[select]

        LanX: our variables are lexical package variables

        haukex: I'm not sure I agree. At least in my mind, package variables are quite different from lexical variables

        You are both correct. our vars are lexical vars. Package vars aren't.

        You seem to be equating our vars and package vars, but that is incorrect. our vars are lexically scoped aliases to package vars.

        Seeking work! You can reach me at ikegami@adaelis.com

[reply]
[d/l]
[select]
        Hi thanks,

        I don't care about 'no strict'.

        Solutions are available by parsing the optree like demonstrated in B::Xref B::Concise and B::Deparse

        But patching them means reinventing the wheel, which I tried to avoid.

        > I'm not sure I agree

        I had the discussion here not long ago. The perldocs are contradictory since our was introduced.

        Lexical is a term borrowed from lisp for variables which have no dynamic scope, but only in the readable block.(lexical ~ like written)

        You know I'm picky about terminology, calling my "private" and package vars "public" would have been better.

        Cheers Rolf
        (addicted to the Perl Programming Language :)
        Wikisyntax for the Monastery

        See also Re^3: Unusual variable declaration ff

[reply]

In Section Seekers of Perl Wisdom