Re: Importing Identifiers from Main::
L. Neil Johnson wrote: > Thanks for the coding critique. You're right. Any idea if either form > evaluates faster? $#array or scalar @array? Find out for yourself: use Benchmark; ... -- ,-/- __ _ _ $Bill LuebkertMailto:[EMAIL PROTECTED] (_/ / )// // DBE CollectiblesMailto:[EMAIL PROTECTED] / ) /--< o // // Castle of Medieval Myth & Magic http://www.todbe.com/ -/-' /___/_<_http://dbecoll.tripod.com/ (My Perl/Lakers stuff) ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: Importing Identifiers from Main::
On Thursday, June 30, 2005 09:33:23 +0200, Johan Lindstrom
[SMTP:[EMAIL PROTECTED] wrote:
> This is what I meant when I said a hash is a good solution to this problem.
> You're not really interested in the order, you want to access each element
> by a convenient name.
>
> It sounds like a bit of data to keep in memory, so going from an array to a
> hash may not be feasible because of that, but if it is it would look like
> this instead:
>
> $trade[$i]->{"time_elapsed"}
>
> If your available memory can take this hit, I'd consider that approach a
> lot more maintainable. If not, go with either exported constants or simply
> $UPPER_CASE_VARIABLES as named indices into the array.
I didn't mean to ignore this approach. I really like it because: 1) The
symbols are contained in the hash and don't have to be imported. And, 2) It's
self-documenting (presume this is what you meant by "maintainable) -- very easy
to read. The memory may not support this design for this particular array, but
I will use it on one, maybe two, smaller arrays. Thank you very much.
> And to me it looks like the solution would be more clear with each record
> being an object, but if you're not familiar with OO, don't start
> introducing it in this program. Try it out with something small and new.
>
> http://www.manning.com/books/conway is excellent.
Thanks for the reference. I remember Conway as the author of Switch.pm.
Should be good.
I appreciate the investment of time and quality of your suggestions.
--Neil
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: Importing Identifiers from Main::
On Thursday, June 30, 2005 1:25 AM, $Bill Luebkert [SMTP:[EMAIL PROTECTED]
wrote:
>
> You could start that package off with a 'package main;' stmt which will
> put you in the same namespace as the calling module.
Good idea. This obviates the need to import identifiers. Rob suggested a
similar approach yesterday.
> You can use an array's scalar context to make this easier to read :
> for (my $i = 0; $i < @{$rT}; $i++) {
Thanks for the coding critique. You're right. Any idea if either form
evaluates faster? $#array or scalar @array?
> # using constants (but you have to export them to the other module like
> your glob refs):
>
> use constant xbi => 0;# index into data arrays, begin time
> use constant xei => 1;# index into data arrays, end time
> use constant xi => 2;# indicator
> use constant xs => 3;# signal
> use constant xa => 4;# amplitude
> use constant xt => 5;# elapsed time
> use constant xr => 6;# trend
I prefer this approach, notwithstanding the need to copy the definitions into
the module(s) that use them: 1) The indices really are constants, and the
pragma makes that clear. 2) Dropping the "$" from the symbol in the anonymous
array index makes it clear when reading the body of the code that the index
isn't going to change (I probably would use all caps in the identifiers to
emphasize this). 3) The identifiers are shorter by one character. 4) If the
compiler in-lines the constant (or subroutine that coughs up the constant), it
may execute faster.
> # using a hash:
>
> my %IX = (
> xbi => 0; # index into data arrays, begin time
> xei => 1; # index into data arrays, end time
> xi => 2;# indicator
> xs => 3;# signal
> xa => 4;# amplitude
> xt => 5;# elapsed time
> xr => 6;# trend
> };
This is also a good idea in that the identifiers are passed with the array, and
there's no need to define them in each module. However, Johanes Lindstrom's
method of using anonymous hashes appeals to me because it's so natural to read.
Bill, I really appreciate your commentary on the code and the expert
suggestions you have made -- as usual.
-Neil
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Importing Identifiers from Main::
$Bill Luebkert wrote: > # using constants (but you have to export them to the other module like > your glob refs): > > use constant xbi => 0;# index into data arrays, begin time > use constant xei => 1;# index into data arrays, end time > use constant xi => 2;# indicator > use constant xs => 3;# signal > use constant xa => 4;# amplitude > use constant xt => 5;# elapsed time > use constant xr => 6;# trend > > # no code change here Actually there is, you have to remove the $'s: > push @tCycle, [$j, $l, $m, $trade[$ii]->[$xi], $phWin, > $trade[$ii-2+$sSC]->[$xa], $trade[$ii]->[$xt] + $trade[$ii-1]->[$xt], > [EMAIL PROTECTED]; push @tCycle, [$j, $l, $m, $trade[$ii]->[xi], $phWin, $trade[$ii-2+$sSC]->[xa], $trade[$ii]->[xt] + $trade[$ii-1]->[xt], [EMAIL PROTECTED]; -- ,-/- __ _ _ $Bill LuebkertMailto:[EMAIL PROTECTED] (_/ / )// // DBE CollectiblesMailto:[EMAIL PROTECTED] / ) /--< o // // Castle of Medieval Myth & Magic http://www.todbe.com/ -/-' /___/_<_http://dbecoll.tripod.com/ (My Perl/Lakers stuff) ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Importing Identifiers from Main::
L. Neil Johnson wrote:
> Thank you for responding. Sorry about the ambiguity. The main program is a
> sequence of computational processes that reads several files of 20K to 50K
> records and splits them into 12 parallel arrays of that length. Analytic
> routines generate an array (@trade) of 2K to 4K elements, each of which is a
> reference to an anonymous array of, say, 7 elements; built like so:
>
> for ($iS=1; $iS<=$#sigs; $iS++) {
> ... # processing...
> push(@trade,[$j,$i,"TaS",$sig,$amp,$elT,$tre[$j]]); # append trade to
> array
> }#for
> [0]begIx,[1]endIx,[2]indic,[3]type,[4]amplitude,[5]elapsedTime,[6]trend
>
> Further on, other processes access this data for analysis, and to build and
> print other arrays, like so:
>
> for ($i=1;$i<=$#trade;$i++) {
> ... # processing...
> push (@tCycle,
> [$j,$l,$m,$trade[$i]->[2],$phWin,$trade[$i-2+$sSC]->[4],
> $trade[$i]->[5]+$trade[$i-1]->[5],[EMAIL PROTECTED]);
> ... # processing...
> }#for
>
> A module was designed (TSP.pm), which contains two subroutines, one which
> prints descriptive statistics, and one which prints performance metrics for
> the
> @trade data. The subroutines, in general, access individual elements of the
> anonymous arrays, like so:
You could start that package off with a 'package main;' stmt which will
put you in the same namespace as the calling module.
> for ($i=0;$i<=$#{$rT};$i++) {
You can use an array's scalar context to make this easier to read :
for (my $i = 0; $i < @{$rT}; $i++) {
> ... # processing...
> $da = int(${$rD}[${$rT}[$i]->[0]]/86400)*86400; # $rT is ref to @trade
> ... # processing...
> }#for
# using constants (but you have to export them to the other module like
your glob refs):
use constant xbi => 0; # index into data arrays, begin time
use constant xei => 1; # index into data arrays, end time
use constant xi => 2; # indicator
use constant xs => 3; # signal
use constant xa => 4; # amplitude
use constant xt => 5; # elapsed time
use constant xr => 6; # trend
# no code change here
push @tCycle, [$j, $l, $m, $trade[$ii]->[$xi], $phWin,
$trade[$ii-2+$sSC]->[$xa], $trade[$ii]->[$xt] + $trade[$ii-1]->[$xt], [EMAIL
PROTECTED];
# using a hash:
my %IX = (
xbi => 0; # index into data arrays, begin time
xei => 1; # index into data arrays, end time
xi => 2; # indicator
xs => 3; # signal
xa => 4; # amplitude
xt => 5; # elapsed time
xr => 6; # trend
};
# $xi then becomes $IX{xi} :
push @tCycle, [$j, $l, $m, $trade[$ii]->[$IX{xi}], $phWin,
$trade[$ii-2+$sSC]->[$IX{xa}], $trade[$ii]->[$IX{xt}] +
$trade[$ii-1]->[$IX{xt}], [EMAIL PROTECTED];
> As mentioned previously, I got tired of editing the absolute indices (e.g.,
> $trade[$i]->[6]) every time the order or meaning of an element of the
> anonymous
> arrays changed; so in main I defined typeglobs:
>
> *xbi = \0;# index into data arrays, begin time
> *xei = \1;# index into data arrays, end time
> *xi = \2;# indicator
> *xs = \3;# signal
> *xa = \4;# amplitude
> *xt = \5;# elapsed time
> *xr = \6;# trend
>
> ...to allow the use of variables for the indices, like so:
>
> push (@tCycle,
> [$j,$l,$m,$trade[$i]->[$xi],$phWin,$trade[$i-2+$sSC]->[$xa],
> $trade[$i]->[$xt]+$trade[$i-1]->[$xt],[EMAIL PROTECTED]);
>
> My question is how best to get those typeglobs into the namespace of module
> TSP.pm so that, when I make a change, it's once in main, and the change is
> automatically propagated into TSP.pm. Right now, I just cut and paste the
> typeglobs from main into TSP.pm. Thank you.
--
,-/- __ _ _ $Bill LuebkertMailto:[EMAIL PROTECTED]
(_/ / )// // DBE CollectiblesMailto:[EMAIL PROTECTED]
/ ) /--< o // // Castle of Medieval Myth & Magic http://www.todbe.com/
-/-' /___/_<_http://dbecoll.tripod.com/ (My Perl/Lakers stuff)
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: Importing Identifiers from Main::
At 07:34 2005-06-30, L. Neil Johnson wrote:
As mentioned previously, I got tired of editing the absolute indices (e.g.,
$trade[$i]->[6]) every time the order or meaning of an element of the
anonymous
arrays changed; so in main I defined typeglobs:
This is what I meant when I said a hash is a good solution to this problem.
You're not really interested in the order, you want to access each element
by a convenient name.
It sounds like a bit of data to keep in memory, so going from an array to a
hash may not be feasible because of that, but if it is it would look like
this instead:
$trade[$i]->{"time_elapsed"}
If your available memory can take this hit, I'd consider that approach a
lot more maintainable. If not, go with either exported constants or simply
$UPPER_CASE_VARIABLES as named indices into the array.
And to me it looks like the solution would be more clear with each record
being an object, but if you're not familiar with OO, don't start
introducing it in this program. Try it out with something small and new.
http://www.manning.com/books/conway is excellent.
/J
-- --- -- -- -- - - -- -
Johan LindströmSourcerer @ Boss Casinos johanl AT DarSerMan.com
Latest bookmark: "TCP Connection Passing"
http://tcpcp.sourceforge.net/
dmoz: /Computers/Programming/Languages/JavaScript/ 12
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Importing Identifiers from Main::
- Original Message -
From: "L. Neil Johnson" <[EMAIL PROTECTED]>
To: "'Sisyphus'" <[EMAIL PROTECTED]>
Cc: "'Win32-Users'"
Sent: Thursday, June 30, 2005 4:22 PM
Subject: RE: Importing Identifiers from Main::
> On Wednesday, June 29, 2005 3:10 AM, Sisyphus
[SMTP:[EMAIL PROTECTED]
> wrote:
> >
> > "Perl in a Nutshell" is quite correct here, I think. If the module does
not
> > have a package name (which is rarely the case) then $var, $::var, and
> > $main::var are all the same thing.
> >
> > D:\pscrpt>type trial.pm
> >
> > sub double_it { return $var * 2}
> > 1;
> >
> > D:\pscrpt>type try.pl
> >
> > use warnings;
> > use trial;
> >
> > $var = 17;
> > $var++;
> > $z = double_it();
> > print $z, "\n";
> >
> > D:\pscrpt>perl try.pl
> > 36
> >
> > D:\pscrpt>
> >
> > I think it's only if trial.pm had a package name (as it normally would)
that
> > 'double_it' would have to be coded as either:
> >
> > sub double_it { return $::var * 2}
> >
> > or:
> >
> > sub double_it { return $main::var * 2}
> >
> Rob, you get credit for a neat example and for an easy solution that may
fit
> (obvious to you, but I never considered it)-- extend main's namespace over
> several files. The reason $var is recognized in double_it() is that
trial.pm
> is still in main's namespace when trial.pm's subroutine is compiled. This
> means that "use trial" in try.pl just looked in the current directory,
found a
> file called trial.pm, assumed it was a module, and went forward with the
> compilation, not caring whether trial.pm had a package declaration or not.
> There was nothing to import since trial.pm didn't export anything.
>
> But, according to Nutshell, trial.pm isn't a module. Note what Nutshell
says
> under Modules (p. 160): "A module is a package defined in a file whose
name is
> the same as the package." Now note what Nutshell says about packages
under
> Namespaces and Packages (p. 160): "Each package starts with a package
> declaration. The package call takes one argument, the name of the
package..."
> So, according to Nutshell, a module must start with a package declaration
that
> includes the name of the package.
>
Yep - I looked at the initial quote you provided from Nutshell which was "If
the package name is null, the main package is assumed", and read that as
meaning "If the package name of the module is null, the main package is
assumed". The only way I could make sense of that was if you had a pm file
that didn't declare a package name. But you're right - in view of the other
text you've quoted it's obvious that my inclusion of "of the module" was way
off. In fact their definition of a module as "a package defined in a file
whose name is the same as the package" is probably *everybody's* definition
so it's hard to come up with an excuse for taking the approach I did
(but I'll continue to work on one :-)
> (Therefore Nutshell still has a problem: $var isn't the same as $::var and
> $main::var if the symbol table changes due to a package declaration, which
must
> be present according to their definition.)
Yes, a package name must be present in a module, but not necessarily present
in a script. And if the script doesn't declare a package name, then $var,
$::var, and $main::var are all one and the same (within that script).
Perhaps that's what they're getting at ??
I don't think they would be meaning that a "$var" within a module could ever
be the same as "$main::var" or "$::var", because clearly that "$var" has
been declared within a package and must therefore be "$package_name::var".
Cheers,
Rob
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: Importing Identifiers from Main::
On Wednesday, June 29, 2005 3:10 AM, Sisyphus [SMTP:[EMAIL PROTECTED]
wrote:
>
> "Perl in a Nutshell" is quite correct here, I think. If the module does not
> have a package name (which is rarely the case) then $var, $::var, and
> $main::var are all the same thing.
>
> D:\pscrpt>type trial.pm
>
> sub double_it { return $var * 2}
> 1;
>
> D:\pscrpt>type try.pl
>
> use warnings;
> use trial;
>
> $var = 17;
> $var++;
> $z = double_it();
> print $z, "\n";
>
> D:\pscrpt>perl try.pl
> 36
>
> D:\pscrpt>
>
> I think it's only if trial.pm had a package name (as it normally would) that
> 'double_it' would have to be coded as either:
>
> sub double_it { return $::var * 2}
>
> or:
>
> sub double_it { return $main::var * 2}
>
Rob, you get credit for a neat example and for an easy solution that may fit
(obvious to you, but I never considered it)-- extend main's namespace over
several files. The reason $var is recognized in double_it() is that trial.pm
is still in main's namespace when trial.pm's subroutine is compiled. This
means that "use trial" in try.pl just looked in the current directory, found a
file called trial.pm, assumed it was a module, and went forward with the
compilation, not caring whether trial.pm had a package declaration or not.
There was nothing to import since trial.pm didn't export anything.
But, according to Nutshell, trial.pm isn't a module. Note what Nutshell says
under Modules (p. 160): "A module is a package defined in a file whose name is
the same as the package." Now note what Nutshell says about packages under
Namespaces and Packages (p. 160): "Each package starts with a package
declaration. The package call takes one argument, the name of the package..."
So, according to Nutshell, a module must start with a package declaration that
includes the name of the package.
(Therefore Nutshell still has a problem: $var isn't the same as $::var and
$main::var if the symbol table changes due to a package declaration, which must
be present according to their definition.)
>
> Your reference to "#define statements" and "constants" makes me wonder
> whether you might want to make use of the constant pragma (see perldoc
> constant), but since I can't quite get a picture of the precise scenario, I
> can't be sure :-)
>
I'll look at this very carefully, not just for this case, but for similar
situations.
>
> Maybe your question is perfectly clear to someone else . otherwise you
> might have to provide a simple little demo module and script to illustrate
> the problem.
In fact my explanation wasn't clear to anyone, and I apologize. Please see my
recent response to Bill Luebkert for a detailed elucidation.
Your comments have been very helpful, and I am very appreciative.
Regards, Neil
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: Importing Identifiers from Main::
Thank you for responding. Please see my detailed explanation, posted to Bill Luebkert recently. On Wednesday, June 29, 2005 10:42:45 +0200, Johan Lindstrom [SMTP:[EMAIL PROTECTED] wrote: > If you're familiar with OO, that sounds like the way to go. You have data. > You have subs that act on this data. That's a class right there. I am not conversant with OO, although this approach sounds interesting. > Create a new module for the constants. > perldoc Exporter or > http://search.cpan.org/~nwclark/perl-5.8.7/lib/Exporter.pm > http://search.cpan.org/~nwclark/perl-5.8.7/lib/Exporter.pm#How_to_Export > http://search.cpan.org/~nwclark/perl-5.8.7/lib/Exporter.pm#How_to_Import This is a good suggestion. I have two reservations: 1) Containment of the number of modules. 2) Good practice would define the constants used as indices in the same namespace as the array that uses those indices (main), not in another module. However, I keep having the same experience with Modula-2 -- end up creating a separate module with constants/structures/etc. common to the other compilation units and have all the other modules import it. Thanks for the references. I may go this direction. --Neil ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: Importing Identifiers from Main::
On Wednesday, June 29, 2005 2:19 AM, $Bill Luebkert [SMTP:[EMAIL PROTECTED]
wrote:
> Your explanation leaves a little to be desired. You could knock it
> down to a single hash that contains pointers to all your arrays if
> that helps. Then you could use names instead of numbers (or not).
> Not sure it's appropriate or not without seeing some access code.
Thank you for responding. Sorry about the ambiguity. The main program is a
sequence of computational processes that reads several files of 20K to 50K
records and splits them into 12 parallel arrays of that length. Analytic
routines generate an array (@trade) of 2K to 4K elements, each of which is a
reference to an anonymous array of, say, 7 elements; built like so:
for ($iS=1; $iS<=$#sigs; $iS++) {
... # processing...
push(@trade,[$j,$i,"TaS",$sig,$amp,$elT,$tre[$j]]); # append trade to array
}#for [0]begIx,[1]endIx,[2]indic,[3]type,[4]amplitude,[5]elapsedTime,[6]trend
Further on, other processes access this data for analysis, and to build and
print other arrays, like so:
for ($i=1;$i<=$#trade;$i++) {
... # processing...
push (@tCycle,
[$j,$l,$m,$trade[$i]->[2],$phWin,$trade[$i-2+$sSC]->[4],
$trade[$i]->[5]+$trade[$i-1]->[5],[EMAIL PROTECTED]);
... # processing...
}#for
A module was designed (TSP.pm), which contains two subroutines, one which
prints descriptive statistics, and one which prints performance metrics for the
@trade data. The subroutines, in general, access individual elements of the
anonymous arrays, like so:
for ($i=0;$i<=$#{$rT};$i++) {
... # processing...
$da = int(${$rD}[${$rT}[$i]->[0]]/86400)*86400; # $rT is ref to @trade
... # processing...
}#for
As mentioned previously, I got tired of editing the absolute indices (e.g.,
$trade[$i]->[6]) every time the order or meaning of an element of the anonymous
arrays changed; so in main I defined typeglobs:
*xbi = \0;# index into data arrays, begin time
*xei = \1;# index into data arrays, end time
*xi = \2;# indicator
*xs = \3;# signal
*xa = \4;# amplitude
*xt = \5;# elapsed time
*xr = \6;# trend
...to allow the use of variables for the indices, like so:
push (@tCycle,
[$j,$l,$m,$trade[$i]->[$xi],$phWin,$trade[$i-2+$sSC]->[$xa],
$trade[$i]->[$xt]+$trade[$i-1]->[$xt],[EMAIL PROTECTED]);
My question is how best to get those typeglobs into the namespace of module
TSP.pm so that, when I make a change, it's once in main, and the change is
automatically propagated into TSP.pm. Right now, I just cut and paste the
typeglobs from main into TSP.pm. Thank you.
-Neil
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Importing Identifiers from Main::
- Original Message -
From: "L. Neil Johnson" <[EMAIL PROTECTED]>
> I was initially misled by PERL in a Nutshell which
> says, under Namespaces and Packages, "If the package name is null, the
main
> package is assumed. For example, $var and $::var are the same as
> $main::var" (p. 160). After more reading and testing, it was determined
> that $var really _must_ be qualified as $::var to be seen in the module.
"Perl in a Nutshell" is quite correct here, I think. If the module does not
have a package name (which is rarely the case) then $var, $::var, and
$main::var are all the same thing.
D:\pscrpt>type trial.pm
sub double_it { return $var * 2}
1;
D:\pscrpt>type try.pl
use warnings;
use trial;
$var = 17;
$var++;
$z = double_it();
print $z, "\n";
D:\pscrpt>perl try.pl
36
D:\pscrpt>
I think it's only if trial.pm had a package name (as it normally would) that
'double_it' would have to be coded as either:
sub double_it { return $::var * 2}
or:
sub double_it { return $main::var * 2}
> Since the qualifier expands these short variable names, and some of the
> lines of code are long as is, I turned away from qualified names. Right
> now, whenever the definitions change in main::, I simply cut and paste
them
> into the module, and all works well. But there are four more big data
> arrays that are in development, and I'm tired of cutting and pasting. (I
> keep thinking about C header files and #define statements...)
>
> Question: What's the best way to handle this situation? Can I export
those
> offsets from main:: and "use" them in the module? Or is there some pragma
> that can be used to generate compile-time constants with global
visibility?
> Any suggestion would be appreciated.
Your reference to "#define statements" and "constants" makes me wonder
whether you might want to make use of the constant pragma (see perldoc
constant), but since I can't quite get a picture of the precise scenario, I
can't be sure :-)
Maybe your question is perfectly clear to someone else . otherwise you
might have to provide a simple little demo module and script to illustrate
the problem.
Cheers,
Rob
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Importing Identifiers from Main::
At 08:57 2005-06-29, L. Neil Johnson wrote: Problem Statement: The main program creates an array of pointers to (Besides the point: there are no pointers in Perl. There are references though.) anonymous arrays, each of which has about 10 elements. Since I am in the development phase, I keep changing the order and identity of the elements. So maybe if the order isn't important you could use a hash instead and use meaningful names (strings) as keys? Because there are many lines of code that reference those elements, I abandoned numeric offsets (indices) and went to variable offsets (actually I use typeglob refs to constants to catch instances where I might accidentally try to change one). I also coded a module with subroutines This also sounds more like a hash. Question: What's the best way to handle this situation? If you're familiar with OO, that sounds like the way to go. You have data. You have subs that act on this data. That's a class right there. Can I export those offsets from main:: and "use" them in the module? Or is there some pragma that can be used to generate compile-time constants with global visibility? Any suggestion would be appreciated. Create a new module for the constants. perldoc Exporter or http://search.cpan.org/~nwclark/perl-5.8.7/lib/Exporter.pm http://search.cpan.org/~nwclark/perl-5.8.7/lib/Exporter.pm#How_to_Export http://search.cpan.org/~nwclark/perl-5.8.7/lib/Exporter.pm#How_to_Import /J -- --- -- -- -- - - -- - Johan LindströmSourcerer @ Boss Casinos johanl AT DarSerMan.com Latest bookmark: "TCP Connection Passing" http://tcpcp.sourceforge.net/ dmoz: /Computers/Programming/Languages/JavaScript/ 12 ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Importing Identifiers from Main::
L. Neil Johnson wrote: > Problem Statement: The main program creates an array of pointers to > anonymous arrays, each of which has about 10 elements. Since I am in the > development phase, I keep changing the order and identity of the elements. > Because there are many lines of code that reference those elements, I > abandoned numeric offsets (indices) and went to variable offsets (actually > I use typeglob refs to constants to catch instances where I might > accidentally try to change one). I also coded a module with subroutines > that manipulate this array, so I'd like to define the offsets in main:: and > simply have their symbols and values trickle down into the module's > (package) symbol table. I was initially misled by PERL in a Nutshell which > says, under Namespaces and Packages, "If the package name is null, the main > package is assumed. For example, $var and $::var are the same as > $main::var" (p. 160). After more reading and testing, it was determined > that $var really _must_ be qualified as $::var to be seen in the module. > Since the qualifier expands these short variable names, and some of the > lines of code are long as is, I turned away from qualified names. Right > now, whenever the definitions change in main::, I simply cut and paste them > into the module, and all works well. But there are four more big data > arrays that are in development, and I'm tired of cutting and pasting. (I > keep thinking about C header files and #define statements...) > > Question: What's the best way to handle this situation? Can I export those > offsets from main:: and "use" them in the module? Or is there some pragma > that can be used to generate compile-time constants with global visibility? > Any suggestion would be appreciated. Your explanation leaves a little to be desired. You could knock it down to a single hash that contains pointers to all your arrays if that helps. Then you could use names instead of numbers (or not). Not sure it's appropriate or not without seeing some access code. -- ,-/- __ _ _ $Bill LuebkertMailto:[EMAIL PROTECTED] (_/ / )// // DBE CollectiblesMailto:[EMAIL PROTECTED] / ) /--< o // // Castle of Medieval Myth & Magic http://www.todbe.com/ -/-' /___/_<_http://dbecoll.tripod.com/ (My Perl/Lakers stuff) ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Importing Identifiers from Main::
Problem Statement: The main program creates an array of pointers to anonymous arrays, each of which has about 10 elements. Since I am in the development phase, I keep changing the order and identity of the elements. Because there are many lines of code that reference those elements, I abandoned numeric offsets (indices) and went to variable offsets (actually I use typeglob refs to constants to catch instances where I might accidentally try to change one). I also coded a module with subroutines that manipulate this array, so I'd like to define the offsets in main:: and simply have their symbols and values trickle down into the module's (package) symbol table. I was initially misled by PERL in a Nutshell which says, under Namespaces and Packages, "If the package name is null, the main package is assumed. For example, $var and $::var are the same as $main::var" (p. 160). After more reading and testing, it was determined that $var really _must_ be qualified as $::var to be seen in the module. Since the qualifier expands these short variable names, and some of the lines of code are long as is, I turned away from qualified names. Right now, whenever the definitions change in main::, I simply cut and paste them into the module, and all works well. But there are four more big data arrays that are in development, and I'm tired of cutting and pasting. (I keep thinking about C header files and #define statements...) Question: What's the best way to handle this situation? Can I export those offsets from main:: and "use" them in the module? Or is there some pragma that can be used to generate compile-time constants with global visibility? Any suggestion would be appreciated. --Neil ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
