|
in reply to Re^4: Indirect variable name
in thread Indirect variable name
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.
|
Re^6: Indirect variable name
by blazar (Canon) on Nov 21, 2008 at 14:10 UTC
|
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] |
|
|
::MY might be what I tried to describe with %PAD stash, a dynamic symboltable for the current scope, making padwalker obsolete.
I personally believe that, as a side note, you may want to hyperlink to PadWalker by means of [mod://PadWalker], stressing incidentally that capitalization does matter.
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.
What a lexically scoped package is, after all, is clear and intuitive. But one point that perhaps I didn't stress enough is the following: if things are still like I claimed them to be, that is that lexical variables are implemented by means of a single magic package, then the latter must have a "slots" for... well, packages too, which sounded somewhat self-referential when I wrote my previous post. On a second thought, though, not just as much... More precisely, I don't see any issue with this circumstance any more. I don't know what I was thinking: anyway, before spending even the slightest braindrop on the subject, I'd like someone who knows better to pinpoint the key elements of it, which we just surfaced here.
| [reply]
[d/l]
[select] |
|
|
|
|
