[22068] in Perl-Users-Digest
Perl-Users Digest, Issue: 4290 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Dec 19 14:11:00 2002
Date: Thu, 19 Dec 2002 11:10:12 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Thu, 19 Dec 2002 Volume: 10 Number: 4290
Today's topics:
Re: Why does Perl handle "return undef;" differently th <asimmons@mitre.org>
Re: Why does Perl handle "return undef;" differently th (Peter Scott)
Re: Why does Perl handle "return undef;" differently th <nobull@mail.com>
Re: Why does Perl handle "return undef;" differently th <asimmons@mitre.org>
Re: Why does Perl handle "return undef;" differently th <asimmons@mitre.org>
Re: Why does Perl handle "return undef;" differently th <uri@stemsystems.com>
Re: Why does Perl handle "return undef;" differently th <nobull@mail.com>
Re: Why does Perl handle "return undef;" differently th <uri@stemsystems.com>
Re: Why does Perl handle "return undef;" differently th <nobull@mail.com>
xmlgrep (bill schaller)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 19 Dec 2002 11:36:51 -0500
From: "Aaron Simmons" <asimmons@mitre.org>
Subject: Re: Why does Perl handle "return undef;" differently then "return;"
Message-Id: <atsshh$72u$1@newslocal.mitre.org>
Thank you. That really does explain it. I do believe in general doing a
"return undef;" is the safest thing to do. Can anyone give me an example of
why doing a "return;" would be better then a "return undef;"?
Here's a HUGE example of why I beleive it is best to do a "return undef;"
################
use CGI;
my $cgi = new CGI();
# ...
updateTable($ID, $cgi->param('FName'), $cgi->param('LName'), $tableName);
################
Since the param method does a "return;" not a "return undef;", the line of
code above is dangerous because updateTable may get 4 arguments passed to
it, or maybe 3, or maybe 2. It depends if 'FName' and 'LName' exist in the
query string (or POST'ed data).
There are many workarounds for the above issue like delcaring the variable,
doing this: "${\$cgi->param('FName')}" or "scalar($cgi->param('FName'))" ---
but that is all just extra code, I feel like the line of code above should
work just fine. It almost makes me want to go back to &ReadParse so I can
do "updateTable($ID, $in{'FName'}, $in{'LName'}, $tableName);" and know it
will always work
Anyway, I've already emailed Licoln Stein about this asking him if there was
a specfic reason why param() does a "return;" rather then a "return
undef;" -- but I know from now on in my code, I will stay away from doing
just "return;" b/c doing so prevents me from safely calling that subroutine
in an argument list.
--
Aaron Simmons
G066-Software Systems Eng, Lead
(703) 883-3394
AaronSimm1 (AIM)
"John W. Krahn" <krahnj@acm.org> wrote in message
news:3E00F921.256DCFCA@acm.org...
> Aaron Simmons wrote:
> >
> > OK, from PerlDoc:
> > "If no EXPR is given, returns an empty list in list context, the
undefined
> > value in scalar context, and (of course) nothing at all in a void
context."
> >
> > So for this code,
> > printArgs('1st', test(), '2nd');
> >
> > test() is being called in a "void context" -- so in order to fix this I
need
> > to do this:
> > printArgs('1st', scalar(test()), '2nd');
>
> No, test is being called in a list context:
>
> $ perl -e'
> printArgs("1st", test(), "2nd");
>
> sub test {return defined(wantarray)?wantarray?"LIST":"SCALAR":"VOID"}
>
> sub printArgs { print join(",", @_) . "\n" }
> '
> 1st,LIST,2nd
>
>
> This is just how lists work. :-)
>
> $ perl -e'
> printArgs("1st", (), "2nd");
> @a = ("1st", (), "2nd");
> printArgs( @a );
>
> sub printArgs { print join(",", @_) . "\n" }
> '
> 1st,2nd
> 1st,2nd
>
>
>
>
> John
> --
> use Perl;
> program
> fulfillment
------------------------------
Date: Thu, 19 Dec 2002 17:12:00 GMT
From: peter@PSDT.com (Peter Scott)
Subject: Re: Why does Perl handle "return undef;" differently then "return;"
Message-Id: <A5nM9.190188$ea.3944988@news2.calgary.shaw.ca>
In article <atsshh$72u$1@newslocal.mitre.org>,
"Aaron Simmons" <asimmons@mitre.org> writes:
>Thank you. That really does explain it. I do believe in general doing a
>"return undef;" is the safest thing to do. Can anyone give me an example of
>why doing a "return;" would be better then a "return undef;"?
next unless new_events_arrived();
...
foreach $events (new_events_arrived()) {...}
...
sub new_events_arrived {
return unless network_connection_open();
...
>Here's a HUGE example of why I beleive it is best to do a "return undef;"
>################
>use CGI;
>
>my $cgi = new CGI();
>
># ...
>
>updateTable($ID, $cgi->param('FName'), $cgi->param('LName'), $tableName);
>
>################
>
>Since the param method does a "return;" not a "return undef;", the line of
>code above is dangerous because updateTable may get 4 arguments passed to
>it, or maybe 3, or maybe 2. It depends if 'FName' and 'LName' exist in the
>query string (or POST'ed data).
That's not a good example IMHO. I would never just pass what a user had entered
for their name into a database without doing some kind of checking first. And if I
did, I'd take less space than you used to avoid the problem:
use CGI qw(param);
updateTable($ID, param('FName')||'', param('LName')||'', $tableName);
>Anyway, I've already emailed Licoln Stein about this asking him if there was
>a specfic reason why param() does a "return;" rather then a "return
>undef;" -- but I know from now on in my code, I will stay away from doing
>just "return;" b/c doing so prevents me from safely calling that subroutine
>in an argument list.
I suggest you reconsider. You will be going against the flow. You'll find
bare returns often in high quality code. Instead of heading off on a less
common path, try doing it their way for a while until you're sure you've
understood all the ramifications.
--
Peter Scott
http://www.perldebugged.com
------------------------------
Date: 19 Dec 2002 17:41:08 +0000
From: Brian McCauley <nobull@mail.com>
Subject: Re: Why does Perl handle "return undef;" differently then "return;"
Message-Id: <u91y4dzz2j.fsf@wcl-l.bham.ac.uk>
"Aaron Simmons" <asimmons@mitre.org> rudely writes TOFU:
> Thank you. That really does explain it.
If you are going thank someone then it is probably a good idea not to
insult them at the same time.
[ Rude TOFU posting corrected ]
> "John W. Krahn" <krahnj@acm.org> wrote in message
> news:3E00F921.256DCFCA@acm.org...
> > Aaron Simmons wrote:
> > >
> > > OK, from PerlDoc:
> > > "If no EXPR is given, returns an empty list in list context, the
> > >undefined
> > > value in scalar context, and (of course) nothing at all in a void
> > > context."
> > $ perl -e'
> > printArgs("1st", test(), "2nd");
> >
> > sub test {return defined(wantarray)?wantarray?"LIST":"SCALAR":"VOID"}
> >
> > sub printArgs { print join(",", @_) . "\n" }
> > '
> > 1st,LIST,2nd
> >
> >
> > This is just how lists work. :-)
> >
> > $ perl -e'
> > printArgs("1st", (), "2nd");
> > @a = ("1st", (), "2nd");
> > printArgs( @a );
> >
> > sub printArgs { print join(",", @_) . "\n" }
> > '
> > 1st,2nd
> > 1st,2nd
> I do believe in general doing a "return undef;" is the safest thing
> to do.
I disagree with "in gerneral". What you say applied only to scalar
functions.
By "scalar function" I mean one for which the follwing are equivalent:
@array = myfunc();
@array = scalar myfunc();
> Can anyone give me an example of why doing a "return;" would be
> better then a "return undef;"?
The natural idiomatic reprentation of the concept "nothing" in a
scalar context is undef.
The natural idiomatic reprentation of the concept "nothing" in a list
context is a empty list.
Therefore if you want to return the concept "nothing" idiomatically
the correct way is "return;" unless you are conciously producing a
scalar function.
> Here's a HUGE example of why I beleive it is best to do a "return undef;"
Oddly enough, it's not only a HUGE example of why you beleive it but
also HUGE example of why you are wrong.
> updateTable($ID, $cgi->param('FName'), $cgi->param('LName'), $tableName);
>
> Since the param method does a "return;" not a "return undef;", the line of
> code above is dangerous because updateTable may get 4 arguments passed to
> it, or maybe 3, or maybe 2.
...or 5 or 6 or 7 or...
> It depends if 'FName' and 'LName' exist in the query string (or
> POST'ed data).
More precisely it depends on how many times FName and LName exist in
the query string, there is nothing particularly special about 0 or 1
occurances.
> There are many workarounds for the above issue like delcaring the variable,
> doing this: "${\$cgi->param('FName')}" or "scalar($cgi->param('FName'))" ---
> but that is all just extra code, I feel like the line of code above should
> work just fine.
What you mean is you feel param() should be a scalar functiomn. But
then would you have param() would have do in the case where a parameter
is multivalued?
> It almost makes me want to go back to &ReadParse so I can
> do "updateTable($ID, $in{'FName'}, $in{'LName'}, $tableName);" and know it
> will always work
If you have a child I strongly recommend you never bathe it. :-)
Perhaps I can interest you in the Vars method from CGI.pm.
> Anyway, I've already emailed Licoln Stein about this asking him if there was
> a specfic reason why param() does a "return;" rather then a "return
> undef;"
You really shouldn't have done this without reading about param() in
the documentation first. There it explains that parameters can be
multivalued.
--
\\ ( )
. _\\__[oo
.__/ \\ /\@
. l___\\
# ll l\\
###LL LL\\
------------------------------
Date: Thu, 19 Dec 2002 12:52:19 -0500
From: "Aaron Simmons" <asimmons@mitre.org>
Subject: Re: Why does Perl handle "return undef;" differently then "return;"
Message-Id: <att0v2$791$1@newslocal.mitre.org>
Yes, I agree that example that I came up with is bogus, I just made it up.
But I'm sure you can agree that there are many valid examples where
embedding "$cgi->param()" in an argument list would be desirable.
Thank you for your [param('keyName')||''] idea -- that's brilliant and the
smallest amount of code change to do what I want...thanks!
By the way, that's a good example of where "return;" makes A LOT of sense,
but I don't think I've ever used "$cgi->param('fieldName')" in a loop
context like while or foreach--I don't see why anyone would ever do that
since isn't "$cgi->param" setup to return the data as an array if that's
what you really want? I will continue to pursure this discussion with
Lincoln. It's his code, his choice, and I am eager to hear his opinion.
In playing around with this problem, I thought I might avoid this general
problem by passing a hash ref instead of individual scalars as arguments
(something I've started to do more and more of recently) -- but that didn't
even work. I'm sure the answer to the problem below is hashes are just
special arrays/lists, but this problem below through me for a loop when I
first discovered it:
#################
printArgValues(
{
'1st' => 1,
'2nd' => test(),
'3rd' => 3
}
);
printArgValues(
{
'1st' => 1,
'2nd' => test2(),
'3rd' => 3
}
);
sub test { return }
sub test2 { return undef }
sub printArgValues
{
foreach (keys %{$_[0]})
{
print "$_:" . $_[0]->{$_} . "\n";
}
print "\n";
}
#################
Because test() returns an empty list, that whole hash definition gets
shifted over -- so '2nd' ends up pointing to '3rd' -- I understand this, it
just seems like very strange behavior.
--
Aaron Simmons
G066-Software Systems Eng, Lead
(703) 883-3394
AaronSimm1 (AIM)
"Peter Scott" <peter@PSDT.com> wrote in message
news:A5nM9.190188$ea.3944988@news2.calgary.shaw.ca...
> In article <atsshh$72u$1@newslocal.mitre.org>,
> "Aaron Simmons" <asimmons@mitre.org> writes:
> >Thank you. That really does explain it. I do believe in general doing a
> >"return undef;" is the safest thing to do. Can anyone give me an example
of
> >why doing a "return;" would be better then a "return undef;"?
>
> next unless new_events_arrived();
> ...
> foreach $events (new_events_arrived()) {...}
> ...
> sub new_events_arrived {
> return unless network_connection_open();
> ...
>
> >Here's a HUGE example of why I beleive it is best to do a "return undef;"
> >################
> >use CGI;
> >
> >my $cgi = new CGI();
> >
> ># ...
> >
> >updateTable($ID, $cgi->param('FName'), $cgi->param('LName'), $tableName);
> >
> >################
> >
> >Since the param method does a "return;" not a "return undef;", the line
of
> >code above is dangerous because updateTable may get 4 arguments passed to
> >it, or maybe 3, or maybe 2. It depends if 'FName' and 'LName' exist in
the
> >query string (or POST'ed data).
>
> That's not a good example IMHO. I would never just pass what a user had
entered
> for their name into a database without doing some kind of checking first.
And if I
> did, I'd take less space than you used to avoid the problem:
>
> use CGI qw(param);
> updateTable($ID, param('FName')||'', param('LName')||'', $tableName);
>
> >Anyway, I've already emailed Licoln Stein about this asking him if there
was
> >a specfic reason why param() does a "return;" rather then a "return
> >undef;" -- but I know from now on in my code, I will stay away from doing
> >just "return;" b/c doing so prevents me from safely calling that
subroutine
> >in an argument list.
>
> I suggest you reconsider. You will be going against the flow. You'll
find
> bare returns often in high quality code. Instead of heading off on a less
> common path, try doing it their way for a while until you're sure you've
> understood all the ramifications.
>
> --
> Peter Scott
> http://www.perldebugged.com
------------------------------
Date: Thu, 19 Dec 2002 13:10:59 -0500
From: "Aaron Simmons" <asimmons@mitre.org>
Subject: Re: Why does Perl handle "return undef;" differently then "return;"
Message-Id: <att222$7bn$1@newslocal.mitre.org>
I know param() can return multivalues. That's not the point of this
discussion. The point of this discussion is why doesn't the following line
of code send in 3 arguments to the subroutine when 'name' is not defined in
the query string or POST'ed data:
subName($a, $cgi->param('name'), $c);
To me, the line above looks like it should always send in at least 3
arguments to subName(), never 2.
Yes, you are correct: if name is a multivalued thing (checkbox, select, or
just multiple anythings), subName will receive more then 3 arguments, but
again I direct you to the original point of this discussion: if it doesn't
exist, why can't param() return undef? Can you give me a good reason why
param() should "return;" instead of "return undef;"?
As to your other comments, John Krahn did an excellent job of explaining to
me that test() was being called in a LIST context and Perl collapses empty
lists. He deserves much thanks for that. I merely went on from my original
generic question about the return function to a more specific question about
CGI::param and the consequences of it returning nothing versus undef for the
case where the name doesn't exist. Thanks for all of your wonderful
input--I'm sure someone, someday will find some use for it.
--
Aaron Simmons
G066-Software Systems Eng, Lead
(703) 883-3394
AaronSimm1 (AIM)
"Brian McCauley" <nobull@mail.com> wrote in message
news:u91y4dzz2j.fsf@wcl-l.bham.ac.uk...
> "Aaron Simmons" <asimmons@mitre.org> rudely writes TOFU:
>
> > Thank you. That really does explain it.
>
> If you are going thank someone then it is probably a good idea not to
> insult them at the same time.
>
> [ Rude TOFU posting corrected ]
>
> > "John W. Krahn" <krahnj@acm.org> wrote in message
> > news:3E00F921.256DCFCA@acm.org...
> > > Aaron Simmons wrote:
> > > >
> > > > OK, from PerlDoc:
> > > > "If no EXPR is given, returns an empty list in list context, the
> > > >undefined
> > > > value in scalar context, and (of course) nothing at all in a void
> > > > context."
>
> > > $ perl -e'
> > > printArgs("1st", test(), "2nd");
> > >
> > > sub test {return defined(wantarray)?wantarray?"LIST":"SCALAR":"VOID"}
> > >
> > > sub printArgs { print join(",", @_) . "\n" }
> > > '
> > > 1st,LIST,2nd
> > >
> > >
> > > This is just how lists work. :-)
> > >
> > > $ perl -e'
> > > printArgs("1st", (), "2nd");
> > > @a = ("1st", (), "2nd");
> > > printArgs( @a );
> > >
> > > sub printArgs { print join(",", @_) . "\n" }
> > > '
> > > 1st,2nd
> > > 1st,2nd
>
> > I do believe in general doing a "return undef;" is the safest thing
> > to do.
>
> I disagree with "in gerneral". What you say applied only to scalar
> functions.
>
> By "scalar function" I mean one for which the follwing are equivalent:
>
> @array = myfunc();
> @array = scalar myfunc();
>
> > Can anyone give me an example of why doing a "return;" would be
> > better then a "return undef;"?
>
> The natural idiomatic reprentation of the concept "nothing" in a
> scalar context is undef.
>
> The natural idiomatic reprentation of the concept "nothing" in a list
> context is a empty list.
>
> Therefore if you want to return the concept "nothing" idiomatically
> the correct way is "return;" unless you are conciously producing a
> scalar function.
>
> > Here's a HUGE example of why I beleive it is best to do a "return
undef;"
>
> Oddly enough, it's not only a HUGE example of why you beleive it but
> also HUGE example of why you are wrong.
>
> > updateTable($ID, $cgi->param('FName'), $cgi->param('LName'),
$tableName);
> >
> > Since the param method does a "return;" not a "return undef;", the line
of
> > code above is dangerous because updateTable may get 4 arguments passed
to
> > it, or maybe 3, or maybe 2.
>
> ...or 5 or 6 or 7 or...
>
> > It depends if 'FName' and 'LName' exist in the query string (or
> > POST'ed data).
>
> More precisely it depends on how many times FName and LName exist in
> the query string, there is nothing particularly special about 0 or 1
> occurances.
>
> > There are many workarounds for the above issue like delcaring the
variable,
> > doing this: "${\$cgi->param('FName')}" or
"scalar($cgi->param('FName'))" ---
> > but that is all just extra code, I feel like the line of code above
should
> > work just fine.
>
> What you mean is you feel param() should be a scalar functiomn. But
> then would you have param() would have do in the case where a parameter
> is multivalued?
>
> > It almost makes me want to go back to &ReadParse so I can
> > do "updateTable($ID, $in{'FName'}, $in{'LName'}, $tableName);" and know
it
> > will always work
>
> If you have a child I strongly recommend you never bathe it. :-)
>
> Perhaps I can interest you in the Vars method from CGI.pm.
>
> > Anyway, I've already emailed Licoln Stein about this asking him if there
was
> > a specfic reason why param() does a "return;" rather then a "return
> > undef;"
>
> You really shouldn't have done this without reading about param() in
> the documentation first. There it explains that parameters can be
> multivalued.
>
> --
> \\ ( )
> . _\\__[oo
> .__/ \\ /\@
> . l___\\
> # ll l\\
> ###LL LL\\
------------------------------
Date: Thu, 19 Dec 2002 18:12:20 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Why does Perl handle "return undef;" differently then "return;"
Message-Id: <x7adj1q3ng.fsf@mail.sysarch.com>
>>>>> "AS" == Aaron Simmons <asimmons@mitre.org> writes:
AS> Thank you. That really does explain it. I do believe in general
AS> doing a "return undef;" is the safest thing to do. Can anyone
AS> give me an example of why doing a "return;" would be better then a
AS> "return undef;"?
in fact as others have stated, you have it backwards. bare return is
MUCH safer and better than return undef. you would be much better off
learning this.
what is printed in this code:
sub bad {
return undef ;
}
$bad = bad() ;
if ( $bad ) {
print "bad scalar\n" ;
}
@bad = bad() ;
if ( @bad ) {
print "bad array\n" ;
}
what you are forgetting in your tirade is perl's powerful use of
context. many builtin functions and module operations use it to decide
on what to return. cgi.pm's param() func does that for a reason, so you
can get one or all values of a param under your control!
if you had no values entered in a form's multivalued widget, what would
you want to happen here:
if ( @vals = param( 'multi' ) {
local $" = ':' ;
print "we got [@vals]\n" ;
}
with your wrong suggestion it would be a bug if no values were entered
in the form.
the scalar() function was created to FORCE scalar context when the
caller wants it. print and all sub calls (without prototypes) provide
list context so scalar is needed to do what you want. so use it and stop
complaining. perl is not going to change this behavior so i suggest you
change the way you think about it. you need to learn more about contexts
and how to work with them and not against them.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
----- Stem and Perl Development, Systems Architecture, Design and Coding ----
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
------------------------------
Date: 19 Dec 2002 18:20:26 +0000
From: Brian McCauley <nobull@mail.com>
Subject: Re: Why does Perl handle "return undef;" differently then "return;"
Message-Id: <u9n0n1yiol.fsf@wcl-l.bham.ac.uk>
"Aaron Simmons" <asimmons@mitre.org> rudely spits TOFU in our faces:
> "Peter Scott" <peter@PSDT.com> wrote in message
> news:A5nM9.190188$ea.3944988@news2.calgary.shaw.ca...
>
> > "Aaron Simmons" <asimmons@mitre.org> writes:
> >
> > >Here's a HUGE example of why I beleive it is best to do a "return undef;"
> >
> > I suggest you reconsider. You will be going against the flow. You'll
> > find bare returns often in high quality code. Instead of heading off on a less
> > common path, try doing it their way for a while until you're sure you've
> > understood all the ramifications.
> Yes, I agree that example that I came up with is bogus, I just made it up.
> But I'm sure you can agree that there are many valid examples where
> embedding "$cgi->param()" in an argument list would be desirable.
So, by all means argue that you want another CGI method that's
equivalent to scalar($cgi->param). Do not argue that the param()
method should change in a grossly backward incompatible way.
> By the way, that's a good example of where "return;" makes A LOT of sense,
> but I don't think I've ever used "$cgi->param('fieldName')" in a loop
> context like while or foreach--I don't see why anyone would ever do that
> since isn't "$cgi->param" setup to return the data as an array if that's
> what you really want?
No. $cgi->param('fieldName') and $cgi->param return completely
different things. For details please consult the relevant manuals.
> I will continue to pursure this discussion with Lincoln.
Please do not do that.
> printArgValues(
> {
> '1st' => 1,
> '2nd' => test(),
> '3rd' => 3
> }
> );
> Because test() returns an empty list, that whole hash definition gets
> shifted over -- so '2nd' ends up pointing to '3rd' -- I understand this, it
> just seems like very strange behavior.
Yes the existance of the LIST v SCALAR context in Perl subroutine
calls can cause some very strange behavior.
But basically what you are arguing against is the very existance of
subroutines that can return lists in Perl. I don't think you'll win
that one.
Actually, if I'd been inventing Perl from scratch then I'd have made
the => operator have a higher precedence than the plain comma and
made => give a scalar context to it's RHS. But it's too late now - we
can't go back in time and change histroy.
--
\\ ( )
. _\\__[oo
.__/ \\ /\@
. l___\\
# ll l\\
###LL LL\\
------------------------------
Date: Thu, 19 Dec 2002 18:40:46 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Why does Perl handle "return undef;" differently then "return;"
Message-Id: <x7k7i5onrm.fsf@mail.sysarch.com>
>>>>> "AS" == Aaron Simmons <asimmons@mitre.org> writes:
AS> I know param() can return multivalues. That's not the point of
AS> this discussion. The point of this discussion is why doesn't the
AS> following line of code send in 3 arguments to the subroutine when
AS> 'name' is not defined in the query string or POST'ed data:
AS> subName($a, $cgi->param('name'), $c);
because it is called in LIST context. period. end of discussion. learn
to use context and scalar. stop your whining as it ain't gonna change.
AS> To me, the line above looks like it should always send in at least 3
AS> arguments to subName(), never 2.
no, it depends on the code in param which LOOKS AT THE CONTEXT.
to your eyes it is wrong. to everyone else's it is correct.
AS> Yes, you are correct: if name is a multivalued thing (checkbox, select, or
AS> just multiple anythings), subName will receive more then 3 arguments, but
AS> again I direct you to the original point of this discussion: if it doesn't
AS> exist, why can't param() return undef? Can you give me a good reason why
AS> param() should "return;" instead of "return undef;"?
because NO ELEMENTS is NOT a scalar undef.
AS> As to your other comments, John Krahn did an excellent job of
AS> explaining to me that test() was being called in a LIST context
AS> and Perl collapses empty lists. He deserves much thanks for that.
AS> I merely went on from my original generic question about the
AS> return function to a more specific question about CGI::param and
AS> the consequences of it returning nothing versus undef for the case
AS> where the name doesn't exist. Thanks for all of your wonderful
AS> input--I'm sure someone, someday will find some use for it.
<snip of ENTIRE quoted EMAIL>
you won't learn anything it seems. stop top posting and stop whining
about param. use scalar already.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
----- Stem and Perl Development, Systems Architecture, Design and Coding ----
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
------------------------------
Date: 19 Dec 2002 18:44:30 +0000
From: Brian McCauley <nobull@mail.com>
Subject: Re: Why does Perl handle "return undef;" differently then "return;"
Message-Id: <u9isxpyhkh.fsf@wcl-l.bham.ac.uk>
Despite having his rudeness pointed out to him "Aaron Simmons"
<asimmons@mitre.org> once again spits TOFU in our faces:
> "Brian McCauley" <nobull@mail.com> wrote in message
> news:u91y4dzz2j.fsf@wcl-l.bham.ac.uk...
> > "Aaron Simmons" <asimmons@mitre.org> rudely writes TOFU:
> >
> > > Thank you. That really does explain it.
> >
> > If you are going thank someone then it is probably a good idea not to
> > insult them at the same time.
> >
> > [ Rude TOFU posting corrected ]
[ And again ]
Are you this rude in meat-space, or is it just in cyberspace?
> > What you mean is you feel param() should be a scalar functiomn. But
> > then would you have param() would have do in the case where a parameter
> > is multivalued?
> >
> I know param() can return multivalues. That's not the point of this
> discussion.
Yes it is. If something is multivalued - i.e. it conceptually a list
then it is possible for it to conceptually be an empty list.
> The point of this discussion is why doesn't the following line
> of code send in 3 arguments to the subroutine when 'name' is not defined in
> the query string or POST'ed data:
> subName($a, $cgi->param('name'), $c);
>
> To me, the line above looks like it should always send in at least 3
> arguments to subName(), never 2.
That just means that you are unfamiliar with Perl.
> Yes, you are correct: if name is a multivalued thing (checkbox, select, or
> just multiple anythings), subName will receive more then 3 arguments, but
> again I direct you to the original point of this discussion: if it doesn't
> exist, why can't param() return undef?
So you are saying that you are calling a function the return value of
which is _conceptually_ a list and you are doing so in a list context
and yet you think it should represent the concept of "nothing to
return" as a list containing a single undefined element.
> Can you give me a good reason why param() should "return;" instead
> of "return undef;"?
Because most people would not agree with you that when calling a
function the return value of which is _conceptually_ a list and doing
so in a list context that the concept of "nothing to return" is best
represented as a list containing a single undefined element.
> As to your other comments,
Since you fail to follow normal quoting conventions (placing you text
after the quoted text to which it referrs) I can only guess which
"other comments" you are referring to. I suspect you are referring to
my criticism of the rudeness you directed towards John Krahn.
> John Krahn did an excellent job of explaining to me that test() was
> being called in a LIST context and Perl collapses empty lists. He
> deserves much thanks for that.
Er, yes... but what, then, did he do to deserve the insult? You do
realise that on Usenet TOFU[1] replies are generally considered to be
an insult don't you?
[1] "Text On-top. Full-quote Under."
--
\\ ( )
. _\\__[oo
.__/ \\ /\@
. l___\\
# ll l\\
###LL LL\\
------------------------------
Date: 19 Dec 2002 17:05:11 GMT
From: schalleb@mayo.edu (bill schaller)
Subject: xmlgrep
Message-Id: <atsu87$jqp$1@tribune.mayo.edu>
Keywords: XML grep search
I need to do grep like functions on files containing mostly xml. I wrote this
little program that works like grep to search through multiple files. You
must specify a root, and each chunck of xml with that root is searched for
additional requirements. If matchs are found, the chunk is printed. As
with grep, this can be piped into other programs....
arguments are a little strange, but run with a -help to figure them out.
--
Bill Schaller N0PUJ bschaller@chartermi.net#!/usr/local/bin/perl
#!/usr/local/bin/perl
while ($_=pop(@ARGV)) {
if (/^-h$/ || /^-he/ || /^-\?/) {
print <<EOF ;
xmlgrep [-help] -root:tag[=value] [-tag:tag[=value] | -arg:arg[=value]] [files]
arguments:
-root:tag[=value] Look for and return xml chunks of this type (value
optional)
-tag:tag[=value] Keep only xml chunks with this tag in it.
-arg:arg[=value] Keep only xml chunks that hav this argument (and value)
-10 List 10 files only
EOF
exit(0);
} elsif (/^-root:(.*)/) {
$_=$1;
if (/(.*)=(.*)/) {
$root = $1; $rootv=$2;
} else { $root=$_; }
} elsif (/^-tag:(.*)/) {
$_=$1;
if (/(.*)=(.*)/) {
$tag = $1; $tagv=$2;
} else { $tag=$_; }
} elsif (/^-arg:(.*)/) {
$_=$1;
if (/(.*)=(.*)/) {
$arg = $1; $argv=$2;
} else { $arg=$_; }
} elsif (/^-(\d+)/) {
$N=$1;
} else { push(@files,$_); }
}
if (!defined($root)) {
print <<EOF ;
xmlgrep [-help] -root:tag[=value] [-tag:tag[=value] | -arg:arg[=value]] [files]
EOF
exit(0);
}
print <<EOF ;
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<XMLgrep>
<XMLgrepSearchTag>Root:$root=$rootv Tag:$tag=$tagv Arg:$arg=$argv</XMLgrepSearchTag>
EOF
$state=0;
if ($#files>=0) {
while ($_=shift(@files)) {
open(F, $_);
$state=0; undef(@sav);
&proc while(<F>);
}
} else {
$state=0; undef(@sav);
&proc while(<>);
}
&finish;
sub finish {
print " <XMLgrepFinish Count=$cnt/>\n</XMLgrep>\n";
exit(0);
}
sub proc { #lazy xml processing here. Assuming new lines between statements!
$state=1 if /<$root[\s>]/ && (!$rootv || / $rootv/);
if ($state>0) {
if ($state==1) {
if (!defined($tag) && !defined($arg)) {
&finish if defined($N) && !$N--;
$state=2; $cnt++;
print @sav; undef(@sav);
} elsif ($tag && /<$tag[\s>]/ && (!$tagv || /$tagv/)) {
&finish if defined($N) && !$N--;
$state=2; $cnt++;
print @sav; undef(@sav);
} elsif ($arg && / $arg[\s=]/ && (!$argv || /"$argv"/)) {
&finish if defined($N) && !$N--;
$state=2; $cnt++;
print @sav; undef(@sav);
} else {
push(@sav, $_);
}
}
print if $state==2;
if (/<\/$root>/ || /<$root.*\/>/) {
$state=0; undef(@sav);
}
}
}
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
The Perl-Users Digest is a retransmission of the USENET newsgroup
comp.lang.perl.misc. For subscription or unsubscription requests, send
the single line:
subscribe perl-users
or:
unsubscribe perl-users
to almanac@ruby.oce.orst.edu.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
To request back copies (available for a week or so), send your request
to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
where x is the volume number and y is the issue number.
For other requests pertaining to the digest, send mail to
perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
sending perl questions to the -request address, I don't have time to
answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 4290
***************************************
