* Richard Morse <remorse at partners.org> [2003-02-10 12:02]:
> Hi!  I'm writing a script which extracts data from a database, and creates a
> new database in a different format.  The idea is to allow investigators to
> extract clinical study data into a format they can analyze.

There's a project on sourceforge that is writing a set of Perl modules,
named SQL::Translator, to do precisely what it sounds like you're doing.
See http://sf.net/projects/sqlfairy/ for details.  There should be a
CPAN release fairly soon, BTW.  I can give you more information on it if
you're interested.

Back to the business at hand ...

> There are certain variables that I want to use in many subprocedures
> in these various packages, so I figured that I could just write "my
> $TEMPDIR = ..." after the use warnings;, and then I'd be able to use
> them in the sub procedures.  After all -- this works when I'm not
> doing many packages.  However, I can't get the value to be used!  When
> referenced from within a sub (like, say, sub dbquote), it evaluates to
> undef, _not_ to "c:/temp", as I have defined it to be.

In addition to being scoped by blocks, "my" variables are also scoped to
the file in which they are delared.  You can get around this by using a
subroutine or method:

sub TEMPDIR () { "c:/temp" }    # or whatever

You would need to reference them with the full package name, i.e.,
sas::TEMPDIR, or as methods if your code is OO: $obj->TEMPDIR(), or
you could use the Exporter and export them.

> I then tried, just for the heck of it, changing the 'my' declarations
> into 'our' declarations.  But this didn't help.

Using "our" should work, provided you reference the variables with their
full names:

  $Some::Variable::In::Another::Package = "foo";

(darren)

-- 
It's not that things are getting worse, it's just that news reporting
is getting better.
_______________________________________________
Boston-pm mailing list
[EMAIL PROTECTED]
http://mail.pm.org/mailman/listinfo/boston-pm

Reply via email to