Re^2: Global variables

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.

Comment on Re^2: Global variables

Replies are listed 'Best First'.
Re^3: Global variables by Joost (Canon) on Oct 02, 2006 at 22:21 UTC
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]

Replies are listed 'Best First'.

Re^3: Global variables
by Joost (Canon) on Oct 02, 2006 at 22:21 UTC

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.

non-global

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...

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]