in reply to our scope and packages

There seems to be very little on the function "our" in manuals and tutorials.

This observation is correct, and that's because there are few if any projects that are not improved by a global s/our/my/.

Of course that will break your existing system of letting everybody share the same global variable. This is generally considered a good thing.

In the file where you declare and populate my %prod, follow it up with an offer to share:

sub get_prod_ref {
    return \%prod;
}

[download]

and now let client files say

use My::Configuration; 
my $prod_ref = My::Configuration::get_prod_ref();
# or if you prefer
my %prod = %{ My::Configuration::get_prod_ref() };

[download]

Replies are listed 'Best First'.
Re: Abandon "our" declarations (was: Re: our scope and packages) (export)
by tye (Sage) on Aug 29, 2008 at 06:45 UTC
    there are few if any projects that are not improved by a global s/our/my/.

    You can easily support use My::Configuration qw( %prod );. Although the basic Exporter.pm doesn't support exporting of lexicals, it is dead easy to support that yourself and I strongly suspect that at least one of the "better exporter than Exporter" modules on CPAN is already written to allow you to export lexicals as well.

    But just to prove how easy it is, if you only have one variable to potentially export, I roll my own exporter as you watch: 

    package My::Config;
use strict;

my %prod = ( foo => 'bar' );
my %export= ( '%prod' => \%prod );
sub import {
    my ( $me, @syms )= @_;
    my $caller= caller();
    for my $sym ( @syms ) {
        my $ref = $export{$sym};
        if ( ! $ref ) {
            require Carp;
            Carp::croak( __PACKAGE__, " does not export $sym\n" );
        }
        $sym =~ s/^[\$\@\%]//;
        no strict 'refs';
        *{ $caller.'::'.$sym }= $ref;
    }
}

    [download]

    Heh, that one isn't even limited to just exporting one variable (it doesn't support exporting groups of symbols yadda, of course).

    - tye        

[reply]
[d/l]
[select]
      It is hard to justify such code in any serious context.

      This is written to be an object method but it effects the object's package namespace not the object.

      This is code that should not be applied to mature code since the My::Config module needs be invaded and all the client code needs to be altered to use it. If there is already a My::Config::import function, it would be better to change the lexicals to package variables inside My::Config.

      If writing new code, such misuse of lexicals is perverse. ... That is the thing I like about it. Ahh.

      Be well,
      rir

[reply]
[d/l]
[select]
        This is written to be an object method but it effects the object's package namespace not the object.

        Um, that statement leaves me unsure what code you were reading when you wrote that. :) What I wrote is closest to being a class method; it certainly isn't an object method. But the similarity it has to being any kind of method at all is only in that it follows the convention set forth in Perl 5 as to how 'use' works. It also doesn't "affect the object's package namespace" (there are no objects involved, so s/object's package namespace/package/); it impacts the namespace of the other package(s) that use this module.

        If there is already a My::Config­::import function, it would be better to change the lexicals to package variables inside My::Config.

        Huh? There was not already an My::Config::import(). There wasn't even a My::Config, there was just a file with no package declaration and an our %prod declaration.

        This is code that should not be applied to mature code since the My::Config module needs be invaded and all the client code needs to be altered to use it.

        If there had already been a My::Config::import(), then the interface would be exactly the same and no "client" code would need to be altered. Code that uses the theorized My::Config should not care at all how the hash you ask to be exported is implemented internally.

        If writing new code, such misuse of lexicals is perverse. ... That is the thing I like about it. Ahh.

        Well, that is a clear statement of opinion. But I wish I could understand the reasoning behind that opinion. (:

        - tye        

[reply]

In Section Seekers of Perl Wisdom