package Model::Conf;

use Exporter 'import';

our @EXPORT = qw( $conf );

our $conf = { 'somevar' => 'somevalue' };

$conf->{'foo'} = bar();


sub bar() { return 'bar'; }
[download]

Add ...

use strict;
use warnings;
[download]

... and perhaps ...

use 5.008_003;
[download]

(because older perls may have older Exporters), then the code looks quite good.

Next step is to think about stopping exporting without explicit request (i.e. move exports from @EXPORT to @EXPORT_OK, think about %EXPORT_TAGS, learn about tag handling utility functions in Exporter).

Then, you could re-think your design. Do you really need to export a variable? Perhaps an object is a much better solution for your problem.

On the other hand, sometimes exporting a variable is the best solution. In some situations, exporting it by default is even better than exporting on demand.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

I'm sure I read somewhere that OO in Perl can slow down compilation and execution time by upto 40%... is that right?

What advantage would there to be gained from objectifying the code when all its meant to do really is act as a config file that doesn't need the processing overhead of parsing XML?

I ask in earnest, as I often wonder what people see in OO and why it seems to be taking over every language.