Re: Bug in libapreq makes form elements stick to an apache child
On Fri, Nov 19, 1999 at 10:10:07AM -0800, Jeffrey Baker wrote:
if (defined @foo_in) {
Generally using defined() on aggregates is a bad idea.
Tim.
Re: Bug in libapreq makes form elements stick to an apache child
Randal L. Schwartz wrote:
"if (@foo) {...}" is *idiomatic* Perl for "are there any elements in
@foo, and if so, do this". If you don't understand the idioms, please
choose a more familiar language. :)
Don't you think this is a rather nasty response, smiley notwithstanding? Normally I
enjoy your posts. Not this one.
Re: Bug in libapreq makes form elements stick to an apache child
On Fri, 19 Nov 1999, Jeffrey Baker wrote:
I don't care whether Perl has allocate memory or not. All I care about
is whether or not there are any defined entries in the list, which I
think is most clearly expressed as 'if (defined $list[0])'. What is
more clear than that? 'if (@list)' could certainly work because an
empty list evaluates to 0 in a scalar context. But the code doesn't
look like what I am intending to do.
Eh, did I miss something? If you really really want to test whether there
are any defined entries anywhere in an array then just testing the
definedness of the first entry isn't going to help. If you really wanted
to do that you could do:
if (grep {defined} @list)
which does what you say you want. 'if (defined $list[0])' would only
check the first entry. 'if (@list)' would return true if '@list = (undef,
undef)'.
-Dave
/*==
www.urth.org
we await the New Sun
==*/
Re: Bug in libapreq makes form elements stick to an apache child
Cliff Rayman wrote: `perldoc -f defined` yields a couple of sentences: You may also use Cdefined() to check whether a subroutine exists, by saying Cdefined func without parentheses. On the other hand, use of Cdefined() upon aggregates (hashes and arrays) is not guaranteed to produce intuitive results, and should probably be avoided. I hate it when that happens. why not use: if(@foo_in) instead of: if (defined @foo_in) Yeah. I guess the reason I do the latter is b/c I want the code to reflect what I am actually trying to test. I don't really want to test the trueness of @foo, I want to test for it's existence. But in perl the operation is overloaded. Feh. I think I will test for defined $foo_in[0] instead. -- Jeffrey W. Baker * [EMAIL PROTECTED] Critical Path, Inc. * we handle the world's email * www.cp.net 415.808.8807
Re: Bug in libapreq makes form elements stick to an apache child
On Fri, 19 Nov 1999, Jeffrey Baker wrote: 1) Visit /yoururl 2) Visit /yoururl?foo=barfoo=baz 3) Visit /yoururl as many times as you have Apache child processes httpd -X -- Matt/ Details: FastNet Software Ltd - XML, Perl, Databases. Tagline: High Performance Web Solutions Web Sites: http://come.to/fastnet http://sergeant.org Available for Consultancy, Contracts and Training.
Re: Bug in libapreq makes form elements stick to an apache child
[EMAIL PROTECTED] (Jeffrey Baker) wrote: Cliff Rayman wrote: `perldoc -f defined` yields a couple of sentences: You may also use Cdefined() to check whether a subroutine exists, by saying Cdefined func without parentheses. On the other hand, use of Cdefined() upon aggregates (hashes and arrays) is not guaranteed to produce intuitive results, and should probably be avoided. I hate it when that happens. why not use: if(@foo_in) instead of: if (defined @foo_in) Yeah. I guess the reason I do the latter is b/c I want the code to reflect what I am actually trying to test. I don't really want to test the trueness of @foo, I want to test for it's existence. But in perl the operation is overloaded. Feh. I think I will test for defined $foo_in[0] instead. Are you sure? I'm still not sure you understand about defined(@list). It actually tests whether Perl has allocated memory for the structure, not whether the structure has ever been used or anything like that. And even the present behavior may change without notice. When you do "my @list = func();" and func returns no values, @list will be an empty list. And it will evaluate in a boolean context to 0 (the number of elements), which is false. You shouldn't really care whether Perl has allocated memory to it or not, because different versions of Perl will give you different results with that test. Finally, what if func returns (undef, 1) or even (undef)? If you use your "defined $list[0]" test, you'll get a false result here, when func actually did return stuff. Of course, I don't know your specific application, but "defined @list" is one of the red flags of code. ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
Re: Bug in libapreq makes form elements stick to an apache child
"Jeffrey" == Jeffrey Baker [EMAIL PROTECTED] writes:
Jeffrey Yeah. I guess the reason I do the latter is b/c I want the code to
Jeffrey reflect what I am actually trying to test. I don't really want to test
Jeffrey the trueness of @foo, I want to test for it's existence. But in perl
Jeffrey the operation is overloaded. Feh.
Jeffrey I think I will test for defined $foo_in[0] instead.
"if (@foo) {...}" is *idiomatic* Perl for "are there any elements in
@foo, and if so, do this". If you don't understand the idioms, please
choose a more familiar language. :)
defined @bar and defined %bletch are almost never correct, and any
seasoned Perl hacker knows to watch for those as a red flag.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
[EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Bug in libapreq makes form elements stick to an apache child
On Fri, 19 Nov 1999, Matt Sergeant wrote: httpd -X good production solution.
