in reply to Changing Local Variable Out of Context

If in the original module, $varry is declared outside the sub and accessed within subs, like this:

package zor; my $varry = "Hello world\n"; sub lol { print $varry; }

Then you should be able to poke at it using PadWalker. It's a bad idea, sure, but it's feasible.

Replies are listed 'Best First'.
Re^2: Changing Local Variable Out of Context
by misterperl (Friar) on Jun 13, 2023 at 17:42 UTC
    In general it's best practice in any programming language to minimize scope, and often, it's helpful to initialize. A var name just *appearing* in a sub, with no local declaration, or not passed in, is at best confusing, and at worst a disaster. It might be defined "miles away" from the sub. The poor bloke maintaining it years from now may have a devil of a time finding it, AND what if it's defined in many places?

    bareblocks help minimize scope, I think about using them whenever I program. Many programmers scope at the "sub" level, but it helps to scope even deeper- within a sub. In general my rules for tite code include:

    a Var's lifetime should be never preceed, or outlast, its usefulness Declare at the last possible moment; go out of scope at the earliest
    Here where I want to get an XML value from a file I might use

    my $XMLval=''; { open X,'myfile'; my @X= grep /<myfavoritetag>/,<X>; last unless @X; $X[0] =~ s/<\/?[^>]+>//g; # shoot the tag and end tag.. $XMLVal=$X[0]; } # here we have $XMLval ready to go , all cleaned up, # and @X is out of scope , # so no worries about it anymore or any other gobbltygook # in the braces

    I could have, and used to, just let @X "hang around" until the sub exited. After 30 years in Perl though, I'm much more conscious of scope and it's hazards.

    It also makes intent clearer- when leaving the bareblock, there is no ambiguity about if @X might be needed, or used, subsequently. Some bloke looking at my code won't have to try to "figure that out" later.

    But worst of all are global vars. To me, using those is like depending on a "side effect". As a min, declare them in main , but where needed, PASS THEM in as a ref or by value.

    Just some musings about scope...
      But worst of all are global vars. To me, using those is like depending on a "side effect". As a min, declare them in main , but where needed, PASS THEM in as a ref or by value.

      Using a global variable as a variable in a procedural manner to store temporary information can be bad, but globals have their place, and especially in perl with the 'local' keyword that allows them to act like environment variables during the scope of a function.

      Also, I'm a fan of end-user freedom, so in all my modules I declare my package variables using 'our' instead of 'my', because it's not for me to judge whether some user of my module should override that or not. That would save the OP from jumping through the hoops of PadWalker just to customize some bit of behavior. (whether a better approach is possible for them is a different argument)

      «But worst of all are global vars…using those is like depending on a "side effect"…where needed, PASS THEM in as a ref…»

      You contradict yourself.

      «The Crux of the Biscuit is the Apostrophe»

        «But worst of all are global vars…using those is like depending on a "side effect"…where needed, PASS THEM in as a ref…» <<You contradict yourself.>>

        No, I dont.

        A var can be global (in main) AND its in the namespace in subs. But even though its scoped globally, for clarity it CAN BE passed in. The fact that it's referenced, or its value is passed in, doesnt change the fact that its scope is global.

        mysub( $::Var )
        Doesn't mean that $::Var is no longer GLOBAL.

        There is no contradiction. Look for value in contributions, not fault.

      But worst of all are global vars. To me, using those is like depending on a "side effect".

      Global variables have their use cases. In Perl, there are probably more than you think. STDERR for example.

      Global variables can be even more important with other programming languages and use cases. For example in Arduinos and other microcontroller applications. When you only got 1024 RAM bytes to work with, you want to be efficient and not "waste" any on unneeded OO stuff.

      PerlMonks XP is useless? Not anymore: XPD - Do more with your PerlMonks XP