The problem is that an object, by definition, encapsulates its data. And yet you wish to externalize some portion of the object's encapsulated data so that it's available to any subs in the package, inaddition to object methods. That's messy. Furthermore, an object is usually "an" instance of a class, not "the" instance of a class. That means you can have several object instances of a class, each with its own separate object data. If there is to be a piece of class data that is the same for all object instances, your use of the global variable is the cleanest solution I can think of, so why jump through hoops to figure out a way to eliminate it?

An object's data isn't intended to be available before the object is created, and yet still unique to the object. You may be able to come up with some contortion using an inside-out object where objects are clones of some parent datastructure, but that's no better than what you've got now, and definately harder to maintain.

I guess my question is why is it so important that you eliminate a package global when it's doing what you want? And would it suffice to create a package-scoped lexical? By creating an outter lexical block that is as broad as the package, and declaring a lexical (my) variable within it, you'll have a variable that looks global to the rest of the package (except there's no entry in the symbol table), but is inaccessible from outside the package (because there's no entry in the symbol table -- assuming that's your goal).

I guess my question is why is it so important that you eliminate a package global when it's doing what you want?

Suppose there are 20 methods each of which is associated with a unique message. Then I would need 20 such variables to go along with them. But your point is well taken.

In OO terms your exported sub the_mascot() ('-' isn't valid in a perl indenntifier :), is a class method.

However, you want this class method to return instance data. And that is a non-sequitous requirement.

Unless this is a singleton class, which is a fancy term for global, in which case you could store the handle ($self) to the one instance into $data and then use $data->{ANIMAL} in the here-doc and you would achieve what you want.

Then you would have to arrange to update $data with the object handle of the lastest incarnation of the singleton everytime new was called.

That's not to say it is the correct way, or the best way to do it, but it would work.

The problem is, if there can be more than one instance of your class, which value of ??->{ANIMAL}, ie. from which instance, should your exported function use?

Unless this is a singleton class, which is a fancy term for global, in which case you could store the handle ($self) to the one instance into $data and then use $data->{ANIMAL} in the here-doc and you would achieve what you want.

Okay, you've got me interested but I'm a bit lost. Could you kindly show me how?

I do not think that this is a good idea but:

The module (with a stupid name for my purposes):

package _424188;
require Exporter;

our @ISA = qw[ Exporter ];
our @EXPORT = qw[ the_mascot ];

my $data = { ANIMAL => "camel" };

sub the_mascot {
    print<<"END";
Hey, did you know that Perl\'s mascot is a:

$data->{ANIMAL}

END

}

sub new {
    my $class = shift;
    return bless $data, $class;
}

sub animal {
    my $self = shift;
    $self->{ANIMAL} = $_[0];
}

sub mascot {
         the_mascot();
}

1;
[download]

And a program that uses it:

#! perl -slw
use strict;
use _424188;

the_mascot();

my $obj = new _424188;
$obj->mascot;
$obj->animal( 'dromadary' );
$obj->mascot;
the_mascot();

__END__
P:\test>424188
Hey, did you know that Perl's mascot is a:

camel


Hey, did you know that Perl's mascot is a:

camel


Hey, did you know that Perl's mascot is a:

dromadary


Hey, did you know that Perl's mascot is a:

dromadary
[download]

---

Examine what is said, not who speaks.

Silence betokens consent.

Love the truth but pardon error.

package Bar;
use strict;

use Exporter;
our @ISA = qw(Exporter);
our @EXPORT_OK = qw(the_mascot);

my $value = "camel";
my $data = \$value;

sub the_mascot {

print<<"END";
Hey, did you know that Perl's mascot is a:

$$data

END
}

sub new {
    my $class = shift;
        my $self = {};
        $self->{ANIMAL} = $data;
        bless($self, $class);
        return $self;
}
 
sub animal {
    my $self = shift;
    ${$self->{ANIMAL}} = $_[0];
}

sub mascot {
         the_mascot();
}

1;
[download]

use strict;
use Bar qw(the_mascot);

my $a = new Bar;
$a->animal("parrot");
$a->mascot;

the_mascot();

$a->animal("firebird");
$a->mascot();

#output
__END__
Hey, did you know that Perl's mascot is a:

parrot

Hey, did you know that Perl's mascot is a:

parrot

Hey, did you know that Perl's mascot is a:

firebird
[download]

What you have proven is that it's possible to declare a lexical at file-scope that works a lot like a package global (but not exactly), but without generating an entry in the package global symbol table. Thus, this file-scoped lexical is not available outside the package (ie, via some fully qualified name, nor outside the enclosing file).

That doesn't show anyone how to cause an object's instance data to be available prior to object creation time, to a package bound sub (or a class method), which seems to be the question.




Dave

package Mascot;

use strict;

use Exporter;
our @ISA = qw(Exporter);
our @EXPORT_OK = qw(the_mascot);

my $value = "camel";

sub the_mascot {
    my $data = shift || $value;
    print<<"END";
Hey, did you know that Perl's mascot is a:

$data

END
}

sub new {
    my $class = shift;
        my $self = {};
        $self->{ANIMAL} = $data;
        bless($self, $class);
        return $self;
}

sub animal {
  my $self = shift;
  my $newval;
  if (ref $self eq __PACKAGE__) {
    $self->{ANIMAL} = $newval = shift;
  } else {
    $newval = $self;
  }
  $value = $newval;
}

sub mascot {
  my $self = shift;
  the_mascot $self->{ANIMAL};
}
[download]