I don't know enough about sockets. is the 0 important? in cases like this can we return 0E0?
0 is very important, in the particular test in my patch. Using 0E0? But then we have an inconsistent API, some places we return undef other 0E0? Granted it is already inconsistent, but the idea is to fix it.
I didn't mean 0E0 instead of undef. I meant 0E0 for 0 - zero but true. that would make only errors return false (undef) while valid values (including zero) would all evaluate to true.
but you won't be able to replace a conditional which doesn't explicitly check for zero.
my $nonblocking = $socket->opt_get(APR::SO_NONBLOCK);
if ($nonblocking) {it will be even more confusing and error prone.
I guess I was asking if the numeric '0' was important in such a way that perl's treatment of 0E0 as 0 would not be sufficient, such as when passing the result of one call (0E0) to another APR method that expected the true integer 0. if perl takes care of the translation then this seems like a real solution.
In this case it's probably going to be used in conditionals, so it is not any different from returning undef, 0, 1. Here you'd code:
my $val = foo();
die "whatever " unless defined $val;
if ($val == 0) {
...
}
elsif ($val > 0) {
...
}This is so much macaroni, compared to:
if (foo()) { # non-zero
...
}
else { # zero
...
}of course adding eval it looks similar:
my $val = eval { foo() };
die "whatever " if $@;
if ($val) { # non-zero
...
}
else { # zero
...
}If you return 0E0 a user putting it in a condition will get wrong logic.
yes, affecting all interpreters for a given (virtual) server.
actually only the current interpreter, you can't affect other interpreter during request time.
if the interpreter scope is per-handler and the new PerlCroakOnFailure is per-directory then you'd have some modules croaking and some not in the same request, right?
Right, which is not good. In which case that flag should be set in the global server structure. And it will still be broken, since one request will run the code that will set it, but won't unset it. and another request not setting it will be affected. It's easy with DBI, since it's all encapsulated in the object which goes away and doesn't affect other code. Here we are in a big mess of having too many different scopes. Not even close DWIM.
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
