|
in reply to Re^3: Indirect variable name
in thread Indirect variable name
if you are more interested in philosophical arguments, there's a fundamental asymmetry between lexicals and entries in the symbol table: lexicals always have names that are identifiers, whereas symbol table entries can have arbitrary names:
I personally believe, speaking of philosophical arguments, that having what that basically boils down to two independent variable systems is particularly annoying especially because they're in fact so similar to each other, thus adding to confusion rather than diminishing it! A posteriori, if say lexical variables looked all that different from package ones, then one would not even think of asking herself why something e.g. "works when variables are declared with our but not with my."
OTOH not only do I cherish the way Perl 6 solves the issue by implementing lexical variables as package variables thus unifying the two systems into one, "just" by means of a special, magic (and then some people still whine that Perl 6 is not magic enough any more...) package, but I... well, personally believe to even be annoying myself for having said so many times how much I would love this feature to be backported to Perl 5. Of course, if it ever were, I don't expect so in terms of an actual implementation, which would be too big a of dream but as a sort of convenient UI to modules like PadWalker & C.
|
Re^5: Indirect variable name
by LanX (Saint) on Nov 20, 2008 at 23:51 UTC
|
Hi blazar,
I agree with you that these are two different variable systems, and the implementation of lexicals is only half way... mainly because a lot of actions on packagevars are not possible with lexicals.
But personally I prefer halfway to nothing!
> OTOH not only do I cherish the way Perl 6 solves the issue by implementing lexical variables as package variables thus unifying the two systems into one, ...
please, could you give me a link explaining this magical unification? My fantasy fails to imagine lexicals as package-vars ... or what exactly do you mean with "lexical variables as package variables" ???
OTH it shouldn't be that difficult to harmonize these two systems... eg. with something like a dynamic hash %PAD for the active block as equivalent to stashes like %main:: ! %PAD would replace the use of padwalker.
| [reply] |
|
|
please, could you give me a link explaining this magical unification? My fantasy fails to imagine lexicals as package-vars ... or what exactly do you mean with "lexical variables as package variables" ???
I personally believe that I may well be the least entitled person to give you any further piece of information. (For any incorrect, imprecise, misleading claim in this post I hope to stand corrected ASAP by the intervention of someone who's more knowledgeable than I am!) For one thing however, packages in Perl 6 are different beasts wrt to their Perl 5 equivalents: for example, typeglobs are gone forever... but IIRC there are more sound and relevant (for the sake of the issue we're discussing here) differences as well. I seem to remember having read, at some point, that lexical variables are nothing but package variables of a magic ::MY package corresponding to the current lexical block. Of course, if all this has not changed, it must be somewhere within Perl 6's docs.
OTOH I also wonder how all this can mix with the fact that we can have lexically scoped packages too! (Declared with my, of course.) Again, if it's still true, then I would like both to see it backported to Perl 5, albeit, as I said, possibly only in terms of UI (well, if some more power could be given en passant that would be not so bad, don't you think so?) and to see how much of it can be backported there, from a consistency and orthogonality POV... (I'm the kind of guy interested in the "phylosophical POV" if it were not clear enough!)
| [reply]
[d/l]
[select] |
|
|
Ok, thx, this makes sence.
::MY might be what I tried to describe with %PAD stash, a dynamic symboltable for the current scope, making [cmod://PadWalker] obsolete. VERY GOOD! 8 )
And I think I can imagine what is meant lexical scoped packages, in perl 5 packages have no privacy at all, you can access them from everywhere. But if the packagename is scoped you may control it.
AFAIK In perl 5 packages are just referenced in the upper stash to be accessible in this namespace, so forming a global tree going up until the main stash %::. But scoping them lexically means to restrict in which scopes namespace they really are accessible. I LIKE this, too! 8 )
Thx for the insight!
UPDATES: adjusting of PadWalker link
| [reply] |
|
|
|
|
|
|
