Consider these alternative ways of saying the same thing:
if(!$ok) {
logFatal("Transfer ($file) to host failed.");
return(0);
}
vs
$ok or return( logFatal("Transfer ($file) to host failed.") && 0 );
The conditional in question pretty much deserves one line in the program logic ("log and return 0"). But is it too much Perl trickery?
I'm obviously in favour of the second one, because I think vertical whitespace matters and size-follows-importance is a good visual design principle.
As I recall, Simon Cozens' talk at YAPC about Artur Bergman's work on the optimizer.pm module mentioned some freaky things like being able to have a subroutine return from the calling subroutine. I was intensely interested because I am doing a lot of Expect.pm work, and that kind of idiom is pretty common in old TCL/Expect scripts. (And blatantly useful in plenty of cases so far with Expect.pm. Lots of callbacks that could benefit.)
I'm not sure if the work in question was mature enough, but if so I think you could actually write a &log_and_return subroutine.
I think he also managed to implement strong typing along the way. Compile time. With no overhead. Or something like that.
I might consider:
or even$ok or
logFatal(), return(0);
But I just think that second one is a bit too nested for me to work out immediately what it's doing.logFatal(),
return(0)
unless $ok;
Re:that second one scares me
jplindstrom on 2002-10-11T16:38:37
How about this one?:)
$ok or return( 0 & logFatal("Transfer ($file) to host failed."));
It's more evident that the 0 is there, but it's still a severe piece of trickery.
Since logFatal() is what it is, maybe a better solution is to redefine it to always return 0 (I never check that return value anyway. Like, what should I do if it fails? Report it somewhere?).
A utility routine should preferrably provide something useful, not complicate your code unnecessarily:)
/J
