in reply to Global variables

I don't really see the advantage of this over Exporter: 
package Foo;
use base 'Exporter;
our @EXPORT_OK = qw(foo_this foo_that);

sub foo_this { ... }

[download]
use Foo qw(foo_this foo_that);

[download]
Having to specify the exporting package is a good thing IMO, since it clarifies where the functions/vars are defined and it makes it possible to re-use "global" names in/from different packages. Both can be useful if your program is growing.

The only downside to Exporter is that it can get a bit verbose. I kind of like the syntax in Perl6::Export::Attrs.

update: s/Perl6::Export/Perl6::Export::Attrs/;

"What should it profit a man, if he should win a flame war, yet lose his cool?"

Replies are listed 'Best First'.
Re^2: Global variables
by polettix (Vicar) on Oct 02, 2006 at 22:02 UTC
    No real advantage, maybe disadvantages. The very difference is that in your approach the programmer has to create package Foo explicitly, while in my toy I wanted to let the user define globals using some "service" from a module. This is probably where the "disadvantage" creeps in: the approach in vars::global is probably too easy, and allows uncontrolled spread of global variables definitions, while in your technique the programmer is kind of obliged to confine all globals together, which leads to better control (and less global proliferation, by application of lazyness).

    If my technique were useful... I think we would have had vars::global in CPAN a long, long time ago ;)

    Flavio
    perl -ple'$_=reverse' <<<ti.xittelop@oivalf

    Don't fool yourself.
[reply]
      The very difference is that in your approach the programmer has to create package Foo explicitly, while in my toy I wanted to let the user define globals using some "service" from a module.
      So in what package are your non-global subroutines defined? :-) update: I mean; you're not defining all your code in the same package, since that would make vars::global unnessicary. But if you're using logical packages anyway, you can use those to export from.
      This is probably where the "disadvantage" creeps in: the approach in vars::global is probably too easy...
      Yeas... but my biggest gripe is that by constricting all globals to vars::global you can't structure your globals into logical packages. I mean, vars::global::query() isn't really as descriptive as MyDatabase::query() or CGI::query()

      I must confess to using main:: as a global namespace sometimes, especially when I'm experimenting, but I try to move as much code as possible into logical classes/packages when the structure becomes clear.

      "What should it profit a man, if he should win a flame war, yet lose his cool?"
[reply]

In Section Meditations