How to declare a variable???

[leiji22]

I'd like to define a large hash at the end of the script file. The hash
contains some parameters.

But I need to use this hash variable at the beginning of the script
file.

The hash is very long, so it's impossible for me to put it at the
beginning of the script.

Do I need to declare it at the beginning of the file? If not, does it
matter where in the file I put the variable definition?

Thanks for any help!

 

[Scott Bryce]

I'd like to define a large hash at the end of the script file. The hash
contains some parameters.

But I need to use this hash variable at the beginning of the script
file.

The hash is very long, so it's impossible for me to put it at the
beginning of the script.

Do I need to declare it at the beginning of the file? If not, does it
matter where in the file I put the variable definition?

Thanks for any help!

I'm not sure exactly what you are trying to accomplish. It looks to me
like you want to define a large data structure near the beginning of
your algorithm, but want to place the code that defines the data
structure near the end of your script for esthetic reasons.


my $large_data_structure = get_large_data_structure();

# Do something with the large data structure here
# $large_data_structure contains a reference to a hash.

sub get_large_data_structure {

my %large_data_structure = (

# Large data structure defined here.

}

return \%large_data_structure;
}

 

[Scott Bryce]

sub get_large_data_structure {

my %large_data_structure = (

# Large data structure defined here.

}

-------^

That should be a ).

 

[John W. Krahn]

I'd like to define a large hash at the end of the script file. The hash
contains some parameters.

But I need to use this hash variable at the beginning of the script
file.

The hash is very long, so it's impossible for me to put it at the
beginning of the script.

Do I need to declare it at the beginning of the file? If not, does it
matter where in the file I put the variable definition?

You could use a subroutine to define it:

#!/usr/bin/perl
use warnings;
use strict;

my %large_hash = define_large_hash();

# many, many, many, many lines of code

sub define_large_hash {
key1 => value1,
key2 => value2,
....
key9998 => value9998,
key9999 => value9999,
}

__END__



John

 

[Anno Siegel]

You could use a subroutine to define it:

#!/usr/bin/perl
use warnings;
use strict;

my %large_hash = define_large_hash();

# many, many, many, many lines of code

sub define_large_hash {
key1 => value1,
key2 => value2,
...
key9998 => value9998,
key9999 => value9999,
}

__END__

Let me show up a few alternatives.

Almost equivalently, the constant pragma can be used:

my %large_hash = LARGE_HASH;

# many, many, many, many lines of code

use constant LARGE_HASH => (
key1 => value1,
key2 => value2,
...
key9998 => value9998,
key9999 => value9999,
);

Using Eric Roode's Readonly (from CPAN) would currently require an
explicit BEGIN block to make sure %large_hash is set early:

my %large_hash;

# many, many, many, many lines of code

use Readonly;
BEGIN {
Readonly %large_hash => (
key1 => value1,
key2 => value2,
...
key9998 => value9998,
key9999 => value9999,
);
}


As of the next version (if I understand correctly) one will be able
to write

my %large_hash;

# many, many, many, many lines of code

use Readonly \ %large_hash => (
key1 => value1,
key2 => value2,
...
key9998 => value9998,
key9999 => value9999,
);

Either way, I notice that with Readonly the declaration "my %large_hash"
would *have* to be commented to the effect that it is set at compile time
further down in the code. That is the cost of saving the intermediate
routine define_large_hash (or LARGE_HASH) of the other solutions, which
make the assignment explicit.

Anno

 

[A. Sinan Unur]

Why use Readonly? Isn't simpler better?

If the hash is going to be used as a lookup table, it might make sense
to prevent it from being changed.

Sinan

 

[xhoster]

I'd like to define a large hash at the end of the script file. The hash
contains some parameters.

But I need to use this hash variable at the beginning of the script
file.

The hash is very long, so it's impossible for me to put it at the
beginning of the script.

How does its size make it impossible to put at the beginning, but possible
to put it at the end?

Anyway, I often do things like this by putting the data in a __DATA__
section, and near the start script reading it into a hash with a "while
(<DATA>)" loop.

Xho

 

[Anno Siegel]

Why use Readonly? Isn't simpler better?

Often. We know too little about how %large_hash is used to tell. I
happened to be interested in how a Readonly solution looks like. I don't
think the OP said explicitly that %large_hash wouldn't be changed, I just
assumed it for convenience.

Then again, I do try to avoid BEGIN blocks when I can by piggy-backing
compile-time action on a use-statement. "BEGIN" looks somewhat alarming,
an everyday "use" is easier on the reader's nerves. The "BEGIN"-solution
*is* simple in being direct, but using a module *looks* simpler. That's
what information hiding is about.

my %large_hash;

# many, many, many, many lines of code

BEGIN {
%large_hash = (
key1 => value1,
key2 => value2,
...
key9998 => value9998,
key9999 => value9999,
);
}

Sure. Like the Readonly solutions that needs a comment where %large_hash
is declared/first used.

Anno

 

[leiji22]

Thanks so much for the alternative solutions!

Very helpful. Have a good holiday season, guys.

 

[Ian Stuart]

If the hash is going to be used as a lookup table, it might make sense
to prevent it from being changed.

Actually, I've come across a few situations where I've wanted to be able
to have a large lookup-table with all the common elements in it, yet
also be able to add some specific "extras" for specific tasks.

For example: MathML::Entities contains some 2,000 XML+XHTML entities
(&foo and the number-code for that entity ('aacute' => 'á').
This is good for 90% of cases, however I have an XML dataset created
from 1980's data, with entities such as &dotlessi; - which are not part
of the XML+XHTML standard.
This means that, to manage this data, I need to extend the
MathML::Entities lookup-table - not possible if it's either a 'my'
variable, locked as a read-only hash, or without a method for adding
records...