Re^4: PadWalker's closed_over - but for our variables?

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}

Comment on Re^4: PadWalker's closed_over - but for our variables?

Replies are listed 'Best First'.
Re^5: PadWalker's closed_over - but for our variables? by haukex (Archbishop) on Apr 03, 2021 at 17:09 UTC
You know I'm picky about terminology, calling my "private" and package vars "public" would have been better. I'm not an expert on the theory and terminology, I'm an engineer and I care more about how things work `;-)` Solutions are available by parsing the optree like demonstrated in B::Xref B::Concise and B::Deparse Yes, I was thinking about these too, it's too bad none of them provide exactly what you want already. B::Xref seems like a decent starting point, unless of course someone has done this already (I don't know yet).	[reply] [d/l]
Re^6: PadWalker's closed_over - but for our variables? by LanX (Saint) on Apr 03, 2021 at 18:19 UTC
> I'm not an expert on the theory and terminology, I'm an engineer and I care more about how things work ;-) OK Wolowitz, but we can agree that wording matters in communication? ;-) > B::Xref seems like a decent starting point unfortunately it's buggy, I'd rather try to reverse "engineer" B::Deparse. Cheers Rolf _{(addicted to the Perl Programming Language :) Wikisyntax for the Monastery}	[reply]