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

Replies are listed 'Best First'.
Re^4: PadWalker's closed_over - but for our variables? by ikegami (Patriarch) on Apr 04, 2021 at 05:38 UTC
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]
Re^5: PadWalker's closed_over - but for our variables? by LanX (Saint) on Apr 05, 2021 at 15:37 UTC
not that easy > our vars are lexically scoped aliases to package vars. the op-tree shows our vars as GVSV with explicit link to a STASH entry `TST::xxx` `D:\tmp\pm>perl -MO=Concise,TST::foo -e"package TST; our $xxx=666; sub +foo { print $xxx}" TST::foo: 5 <1> leavesub[1 ref] K/REFC,1 ->(end) - <@> lineseq KP ->5 1 <;> nextstate(TST 3 -e:1) v ->2 4 <@> print sK ->5 2 <0> pushmark s ->3 - <1> ex-rv2sv sK/1 ->4 3 <#> gvsv[TST::xxx] s ->4 -e syntax OK` [download] while illguts° states `Lexicals (my and our variables) have SVs_PADMY / SVs_PADOUR` My experiments show that deleting the stash entry prior to running the code doesn't effect the correct execution. Hence I think that the refs are hardcoded (bound) into the op-tree and STASHs and PADs are primarly for lookup at compilation time. (plus ref-counting) My experiments also showed that deleting the alias of an 'our'-var from the STASH forced a destruction of that var at the end of the scope, much like with 'my'-vars. So I'm inclined to think that Concise is just showing an interpretation of the refadress in the optree. Anyway all this confusion stems from fuzzy wording. We should stop referring to private my-vars as "lexicals". A distinction between "private" and "public" would be far better. "lexical" should be reserved for the scope only and contrasted with "dynamic" ² Consequence: an our-var is a "lexical and public" variable. NB: I'm also contrasting "public" from "global", because only special vars like $_, $\| or $a are really global, they always belong to `main::` Cheers Rolf _{(addicted to the Perl Programming Language :) Wikisyntax for the Monastery} °) "Illustrated Perl-Guts" ... is it only me, or does "illguts" make you think of diarrhea? update ²) in hindsight, lets avoid "lexical scope" and rather use the synonymous "static scope"	[reply] [d/l] [select]
Re^6: PadWalker's closed_over - but for our variables? by ikegami (Patriarch) on Apr 05, 2021 at 21:59 UTC
because only special vars like $_, $\| or $a are really global Nah, all package variables are globally scoped (visible globally). The variable you listed simply have a different default namespace if you use them unqualified. That doesn't change their scope. Seeking work! You can reach me at ikegami@adaelis.com	[reply]
Re^7: PadWalker's closed_over - but for our variables? by LanX (Saint) on Apr 05, 2021 at 22:01 UTC
Re^8: PadWalker's closed_over - but for our variables? by ikegami (Patriarch) on Apr 05, 2021 at 22:06 UTC
Some notes below your chosen depth have not been shown here
Re^4: PadWalker's closed_over - but for our variables? by LanX (Saint) on Apr 03, 2021 at 16:55 UTC
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]
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]

update