David,
this appears to be exactly what i was looking for, and i thank you with
infinite groveling *g*. the reason i wanted something like this is
because i like to name my variables and cgi parameters the same as my
database fields - $school_id = school_id (cgi parameter) = school_id
(mysql field). i plan on using this to allow the passing of the name
w/o the "$" to a sub and having it construct all necessary destinations
dynamically since all names will be as identical as possible.
if you know of a better way to accomplish the end result, i'm all for
it. this is just the best i could come up with for now.
hopefully my description makes sense. thanks to all for their help.
joe
On Mon, 2003-01-13 at 13:58, david wrote:
> Joe Mecklin wrote:
>
> > Dan,
> >
> > here is the output with your additions.
> >
> > BEFORE :: ID - 101
> > NM - Arapaho Elementary
> > AD - 1300 Cypress Dr.
> >
> > # this is the call to clear_input in ISD.pm
> > $fields = school_id, school_name, school_address
> > @field = school_id school_name school_address
> > $f = school_id = ..
> > $f = school_name = ..
> > $f = school_address = ..
> >
> > AFTER :: ID - 101
> > NM - Arapaho Elementary
> > AD - 1300 Cypress Dr.
> >
> > # this is the output to clear_input2 in school_data (all code in
> > the same file)
> > $fields = school_id, school_name, school_address
> > @field = school_id school_name school_address
> > $f = school_id = .101.
> > $f = school_name = .Arapaho Elementary.
> > $f = school_address = .1300 Cypress Dr..
> >
> > both routines are carbon copies of each other. i used "our" simply to
> > see if it might affect how the data got passed to ISD. no effect. but
> > while writing this, i changed them back to "my" and the clear_input2
> > call no longer displayed the values. God keep me from being bored with
> > simplicity *g*.
> >
> > also, while the ultimate goal is to null the variables, currently all
> > i'm doing is printing out the values of the variables being referred to
> > in the arguments being passed to clear_input() and clear_input2(), on
> > the premise if i can't read the existing data in those variables, i
> > won't be able to write new data to those variables.
>
> i didn't follow the thread closely but what you are missing could be the
> name of the package where the variables are declared. without it, Perl
> search the variable in the current package (and it's Export list for one)
> and if it can't find it, it wouldn't be able to use it. also remember that
> once you tag your variables with 'my' ('our' is ok of course), they won't
> exist in the symbol table and thus you can't effectively symbolic
> de-reference them. to give you an idea, take a look at the following
> script:
>
> #!/usr/bin/perl -w
> use strict;
>
> package Apple;
> sub apple{
>
> #--
> #-- without caller(), the following won't
> #-- work because Perl doesn't know which symbol
> #-- table to search for $j
> #--
> my $i = caller() . '::' . shift;
>
> no strict 'refs';
> print "$$i\n";
>
> #--
> #-- change it
> #--
> $$i = 5678;
> }
>
> package main;
>
> #--
> #-- if you tag $j with 'my', you are telling
> #-- Perl that you don't want $j to be in the symbol
> #-- table of main which you can't effectively symbolic
> #-- de-reference it in your Apple package
> #--
> our $j = 1234;
>
> Apple::apple('j');
>
> #--
> #-- reflect new value
> #--
> print "$j\n";
>
> __END__
>
> prints:
>
> 1234
> 5678
>
> i don't know why you want symbolic reference but many people (including me)
> will tell you that this's very dangerous and you should avoid that as much
> as possible.
>
> david
>
> --
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
