in reply to What to use instead of global variables

One of the programming virtues often talked of in the context of Perl in particular is laziness. The rational is that laziness means doing the least amount of work over the lifetime of a piece of code, not just "right now". In the case of globals that generally means don't use em because over the lifetime of a script they are likely to lose you more time than they save due to "action at a distance" bugs.

However global variables are not really the issue in the sketch code you have shown. A bigger issue is using &subname to call subs instead of subname() - that really doesn't do what you think it does. Another issue is the suggestion of use of 'switch' which is not a Perl construct, but if you use 5.010 you can use given/when instead.

But your real issue seems to be sharing variables outside their package. That is a special case of "global variables" and can be ok in some situations, but mostly isn't. However your code looks much more like it should make use of object oriented techniques. Ok, some big or unfamiliar words there I suspect, but OO needn't be that frightening. Consider:

use strict; use warnings; use 5.010; package LibStuff; sub new { my ($class, %params) = @_; return bless \%params, $class; } sub picker { my ($self) = @_; my @keys = keys %$self; return $keys[rand @keys]; } sub getter { my ($self, $param) = @_; return "$self->{$param}"; } sub sub0 { my ($self) = @_; say $self->{0}; } sub sub1 { my ($self) = @_; say $self->{1}; } sub subWibble { my ($self) = @_; say $self->{wibble}; } package main; my $libObj = LibStuff->new(0 => 'a', 1 => 'b', wibble => 'c'); say $libObj->getter($libObj->picker()); given ($libObj->picker()) { when ('0') {$libObj->sub0()} when ('1') {$libObj->sub1()} when ('wibble') {$libObj->subWibble()} }

The class is the name of the package: LibStuff. new is a constructor and makes a LibStuff object so $libObj gets assigned a LibStuff object (an "instance" of the LibStuff class).

The other subs in the LibStuff package are members of LibStuff and the $self variable is the instance (the thing that got assigned to $libObj) the method is working with.

The only really magic bit is bless which takes a reference to something (in this case a hash) and a name and creates a blessed reference (an object). Once you have an object you call methods on it using syntax like $libObj->picker().

So what does that have to do with global variables? Well nothing really because you tend not to need them any more. The object packs everything it needs up inside itself and carries it around wherever it goes. The methods provide the usual ways of manipulating the contents of the object so it's much easier to ensure that the manipulation is correct and that removes a lot of the action at a distance issue that global variables engender. It also makes maintenance easier because the only code that fools around with the data is likely to be together in one place so again it's easier to ensure manipulation is correct.

True laziness is hard work