in reply to Re^2: standard perl module and BEGIN block.
in thread standard perl module and BEGIN block.

And here I was under the impression that my pointing out the trick was a comment.. :-D

Seriously now, you're right that it does make that section of the code depend on position. Which I don't see as a horrible thing - no worse than a lexically scoped variable. And certainly not in boilerplate initialization code which many people who use it won't expect to understand.

If you're uncomfortable with that fact you can always declare the variables as is usually done. In fact I pointed out that I'd done it so that people could make that choice.

Also I deliberately didn't comment on the mechanics. If I thought that the mechanics required commenting on within the code, then I'd first try to solve that by changing the mechanics, not commenting the code.

  • Comment on Re^3: standard perl module and BEGIN block.

Replies are listed 'Best First'.
Re^4: standard perl module and BEGIN block.
by BrowserUk (Patriarch) on Aug 16, 2004 at 21:47 UTC

    My thinking that a comment in the boiler plate code would be appropriate as once code gets into a module, those coming along after may not appreciate it's source or significance.

    Avoiding globals all together would be the best route, but that's not currently possible for the likes of these "special variables".

    For a long time I didn't really appreciate your concerns regarding our, but having quite recently been bitten by a typo in an our var, they can indeed cause mysterious problems.

    I guess what I would really like, whilst doing away with globals completely is not an option, would be a combination of the two; use vars; and our.

    The former would indicate those globals I intended to use and disable the warnings/strictures on them--but only within those scopes where I had used our for that same variable.

    Using our for a var that hadn't previously been declared with use vars would raise an error. As would attempting to use a global mentioned in use vars, without also having scoped it using our.

    I'm not really a S&M type, and that does sound like "belt & braces" even to me, but given my propensity for typos, and the number of saves that "Global symbol "$x" requires explicit package name.." makes on my behalf, I would welcome this ability.

    Examine what is said, not who speaks.
    "Efficiency is intelligent laziness." -David Dunham
    "Think for yourself!" - Abigail
    "Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon
[reply]
[d/l]
[select]

      I'm just curious here, but your looking for something that would look like... 

      package Some::Package;
use vars qw/test/;

sub inHere {
    our $test;
}

      [download]

      If so I think that would be far more intuitive than the current setup. After a year of perl I still have no concept of our.


      ___________
      Eric Hodges
[reply]
[d/l]
[select]

        Yes. And in this code: 

        package Some:Module;
use vars q/test/;

## Here "Global symbol "$test" requires explicit package name".
$test = 1; 

sub inHere {
    our $test; # ok.
    our $tset; # typos/thinkos causes errors.
    my $test;  
# my variable "$test" overrides variable with the same name at differe
+nt scope...
}

1;
Some::Other::Module;

sub inThis {
    our $test; ## is an error.
}

        [download]

        If it is possible to get this behaviour, changing use vars; to work this way would probably cause backward compatibility issues, so maybe use globals qw/$var @var %var/; would make more sense.

        That said, maybe something like $var : global = 1; would be more in keeping with the latest trends and prehaps more compatible with P6.

        Examine what is said, not who speaks.
        "Efficiency is intelligent laziness." -David Dunham
        "Think for yourself!" - Abigail
        "Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon
[reply]
[d/l]
[select]

      Using our for a var that hadn't previously been declared with use vars would raise an error. As would attempting to use a global mentioned in use vars, without also having scoped it using our.

      The difference between use vars and our is that the former allows a module's variables to be used from outside the module. 

      # Would warn if Data::Dumper used 'our' instead of 'use vars'.
local $Data::Dumper::Useqq = 1;

      [download]

      Your idea would reverse the purpose of use vars. Instead of allowing a variable to be used outside the module, it would prevent the variable from being used outside the module.

      The underlying idea is good, but you'd need to use something other than use vars.

[reply]
[d/l]
[select]

      Great idea. I'm pretty sure Perl 6 didn't adopt something like this.

      - tye        

[reply]
        Great idea.

        Really?

        I'm pretty sure Perl 6 didn't adopt something like this.

        I think it is still too early to say. The P6 spec seems more undefined now than it was when I posted that.

        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.
[reply]

In Section Seekers of Perl Wisdom