Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid
 
PerlMonks  

Re^3: aliasing arrays using typeglob under strict

by AnomalousMonk (Abbot)
on Feb 08, 2013 at 16:13 UTC ( #1017848=note: print w/ replies, xml ) Need Help??


in reply to Re^2: aliasing arrays using typeglob under strict
in thread aliasing arrays using typeglob under strict

Nothing associated with [the temporary use of localise] persists beyond the lexical scope in which the aliasing is performed.

I disagree. In my understanding, the dynamic scope of a function in respect of package (or global) variables extends to all functions called by the function, in contrast to lexical scope, which is, well, lexical.

So in the example code below, the function  G() can exercise "spooky action at a distance" on data localized in the  F() function because  G() executes within the dynamic scope of  F().

One may say that this effect may be avoided by remembering to carefully localize all package variables in all called functions, but this is just the sort of 'care' that one so often forgets to exercise in one's own behalf, to say nothing of all the other stumblebums out there.

IOW, not using global variables is very well-founded paranoia: sometimes those globals really are out to get you! There's a place for globals, gotos, and a host of other 'questionable' programming constructs, but they should always be approached accompanied by a healthy dose of paranoia.

>perl -wMstrict -le "my @ra = (9, 8, 7, 6); ;; F(\@ra); ;; sub F { our @ydata; local *ydata = shift; print qq{pre-G: (@ydata)}; G(); print qq{post-G: (@ydata)}; } ;; sub G { our @ydata = 'Gaaaahh!'; } " pre-G: (9 8 7 6) post-G: (Gaaaahh!)


Comment on Re^3: aliasing arrays using typeglob under strict
Select or Download Code
Re^4: aliasing arrays using typeglob under strict
by BrowserUk (Pope) on Feb 08, 2013 at 16:41 UTC
    One may say that this effect may be avoided by remembering to carefully localize all package variables in all called functions,

    Unintended side effects are unintended side effects:

    sub G { our @ydata = 'Gaaaahh!'; };; sub F{ my @a = @_; print qq{pre-G: (@ydata)}; G(); print qq{post-G: (@ydata)}; };; F(1..4);; pre-G: () post-G: (Gaaaahh!)

    The problem has nothing to do with aliasing and everything to do with not localising!

    Your previous quote is better stated as: "don't use code that uses globals for no good reason.".

    Which is doubly true for code that fails to localise its use of globals.

    a healthy dose of paranoia.

    Sorry, but I will always consider 'paranoia' in programming -- and pretty much everything else for that matter -- with exclusively negative connotations.

    The teaching of 'paranoia', rather than 'knowledge', in an attempt to avert disaster, is always a counter productive and ultimately futile process.

    With paranoia, one can only hope to avert bad consequences; with knowledge one can know you have.

    Don't hope, know!


    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
      Unintended side effects are unintended side effects... The problem has nothing to do with aliasing and everything to do with not localising!

      But surely the soul of wisdom is to avoid unintended consequences.

      With paranoia, one can only hope to avert bad consequences; with knowledge one can know you have.
      Don't hope, know!

      Again, this is utterly without consideration of effects on performance, but in general, shouldn't one prefer the avoidance of a coding technique that depends on local-izing everything in sight in favor of one that takes advantage of the lexical scope associated with every subroutine definition by using only lexical variables? By so doing, one may know one has averted bad consequences – at least outside the lexical scope of the subroutine one is examining at the moment. (BTW: Is it possible to define a subroutine without creating a unique lexical scope for it? Offhand, I can't see a way.)

      Oh well... Perhaps not even USD0.02-worth on this one. Anyway, I have to go shovel some snow now.

        But surely the soul of wisdom is to avoid unintended consequences.

        And

        Is it possible to define a subroutine without creating a unique lexical scope for it? Offhand, I can't see a way.

        No, But that doesn't completely negate the possibilities of unintended consequences.

        Eg. As you follow the fairly common practice of placing your subroutines after your 'main' code; the possibilities for unintentional (and silent) closures abound.

        Again, this is utterly without consideration of effects on performance,

        Out of context, that sounds like I'm favoring this technique for performance. But if you read back, I'm most definitely not.

        (More on this in response to your other post.)

        that depends on local-izing everything in sight

        Such exaggerations do not advance the discussion :)


        With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1017848]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (4)
As of 2014-09-20 00:17 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (151 votes), past polls