--- David Gilden <[EMAIL PROTECTED]> wrote:
> Did I touch a nerve here or what?
LOL!!!
It happens. ;o]
> Ge, all of this totally <favorite slang word> is confusing me,
Haven't got a clue what you mean..... ~grin~
> So you know where I am coming from, I'm taking
> a second on-line CGI/PERL class that leaves a lot to be desired (if
> anyone knows a good up-todate on-line class, please let me know!)
I could suggest nothing better than to take an hour out or two, read
through the CGI.pm docs, and write some test code for anything that
doesn't gel for you. It'll be time well spent, that you'll spend anyway
later if you don't. Better to do it now than waste the time debugging
later and have to do it anyway when you're already even more frustrated
and confused. <nodnodnod>
> I will move up to learning CGI.pm, but for this month, I need to
> learn how share variables between PERL files.
> So by way of example what do I need to add to my code so I can use
> the Strict Pragma?
1) Make them global.
It's sloppy, but it's quick. Always refere to the variable in
question as $package::name, and it'll be fine. For example:
$main::x = 1; # puts this in the main namespace
$Global::y = 2; # puts this in "Global" namespace
Note that both of these are "Global". Any code anywhere in the program
can read them. main:: is where all your stuff goes by default, but by
saying "Global" (there's nothing magical about the word -- it could
have been "Foo" or "George" or whatever), you put it into the Global::
namespace. strict.pm won't let you just say $x because it's watching
your back, but $My::x is fine, because you went to the extra trouble to
tell it which x you want. It won't create $x for you, but will quietly
make a $My::x or a $main::x or $whatever::x for you, because you gave
it enough info to believe you know what you are doing.
2) Pass them explicitly.
This is a better way to do it, but from the sound of it, you'd have
to rearrange code a bit. It might not be worth it in this case,
especially with time constraints. Your call.
3) Make accessors.
If in your require'd file you create say
my($x) = 1;
then $x is fine, strict is happy, but $x *ONLY* exists in the scope of
the file in which it was declared, and can only be accessed from that
scope. If, however, you were to add an accessor function in the same
scope:
sub x {
$x = shift if @_;
$x;
}
then I *believe* the function would go into your current namespace, but
would still have access to the commonly scoped variable. That way, you
could get/set the var with that function, like so.
x(2);
print x();
Yes, it seems a little abstracted, but it's a big step on the road to
objects, which (tho you may never need them) are tried-and-true.
> I take it that this is considered bad programing style or is just out
> date, like the <blink> tag in <html> :)
> require "libcgi2.pl";
Kinda, lol....
> Also I don't understand this '::' syntax.
That's just Perl's way of specifying where to look for a global.
Anything that's in a package is globally available to anything that
knows where to look, but packages are like rooms in the global house;
you can walk into them without a key, but only if you know where they
are. $main::x isn't the same variable as $My::x, even though both are
x, and both can be gotten from the main or My or Foo namespaces.
Scope is *entirely* another thing, in that a lexical (my()'d) variable
only exists in the scope in which it was created.
Consider the following:
package main; # now in main:: (this is the default)
my $x = 1;
$main::x = 2;
$foo::x = 3;
package other;
$other::x = 4;
Now, if I say
print $foo::x;
It prints 3, but if I just say
print $x;
It prints 1, because my() pays no attention to namespace, and *all*
these are in the same *scope*. =o)
Now, I realize that may be confusing, but hopefully better minds will
expand and correct where I've babbled! lol....
=====
print "Just another Perl Hacker\n"; # edited for readability =o)
=============================================================
Real friends are those whom, when you inconvenience them, are bothered less by it than
you are. -- me. =o)
=============================================================
"There are trivial truths and there are great Truths.
The opposite of a trival truth is obviously false.
The opposite of a great Truth is also true." -- Neils Bohr
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35
a year! http://personal.mail.yahoo.com/
