return explicit undef - Best Practices?

Boldra has asked for the wisdom of the Perl Monks concerning the following question:

I've recently switched over to using naked returns and hit this problem.

A method '$park->has_dinosaurs' returns a boolean. Another subroutine, 'stop' passes its arguments as an anonymous hashref.

stop( { name            => $name,
        stop_dinosaurs  => $park->has_dinosaurs,
        timeout_seconds => $config{stop_timeout}, } );
[download]

'has_dinosaurs' was written according to PBP, and therefore returns either '1' or the default value of return.

When 'has_dinosaurs' returns false (nothing), the 'stop' call produces a runtime warning "Odd number of elements in anonymous hash", and then a runtime error inside &stop, because 'timeout_seconds' wasn't defined. The placement inside an anonymous hash seems to force array context (which seems a little odd). Call context checking inside has_dinosaurs won't help, without also breaking exactly what PBP 9.12 is supposed to prevent. What do people suggest?

- Boldra

Comment on return explicit undef - Best Practices? Download Code

Replies are listed 'Best First'.
Re: return explicit undef - Best Practices? by JavaFan (Canon) on Dec 09, 2008 at 12:08 UTC
Don't take PBP as a set of laws. PBP is a set of guidelines. And it isn't so much about what the rules say, the value of PBP lies in its motivation. I very much prefer to work with a programmer who has reasons to reject all the rules in PBP, then a programmer who can quote chapter and verse which rule(s) a particular statement of his follows, but only does so because PBP says so. Clearly, if a following a rule from PBP breaks your code, and you have to do unnatural things to unbreak it, it's not a good idea to follow said rule. If you have a function that is supposed to return in list context, a one element list with a false value (and you seem to have such a function), then "return undef" is perfectly reasonble.	[reply]
Re: return explicit undef - Best Practices? by BrowserUk (Patriarch) on Dec 09, 2008 at 11:50 UTC
What do people suggest? Establish a scalar context explicitly: `stop( { name => $name, stop_dinosaurs => scalar $park->has_dinosaurs, timeout_seconds => $config{stop_timeout}, } );` [download] Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. "Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."	[reply] [d/l]
Re: return explicit undef - Best Practices? by shmem (Chancellor) on Dec 09, 2008 at 15:53 UTC
'has_dinosaurs' was written according to PBP, and therefore returns either '1' or the default value of return. There is no default value of return. But if you want to say that in your code there's a bare return, it doesn't return anything, i.e not even a single 'undef' which would be a one element list in list context. If you want the value for the key 'stop_dinosaurs' explicitly set, you could say `stop_dinosaurs => $park->has_dinosaurs ? 1 : 0,` [download] but if you want to skip that key/value pair completely if `$park->has_dinosaurs` returns a false value, then `(stop_dinosaurs => 1 ) x ! ! $park->has_dinosaurs,` [download] would make the list `(stop_dinosaurs, 1)` disappear, if `$park->has_dinosaurs` evaluates to false. See Binary "x" in perlop.	[reply] [d/l] [select]
Re: return explicit undef - Best Practices? by Boldra (Curate) on Dec 09, 2008 at 12:34 UTC
Thanks for the suggestions, I think I've found a clear answer. The rule I was looking at (PBP 9.12) is "returning failure". This isn't actually a case of returning failure, rather one of returning falsehood. So I'm going to go with JavaFan and explicitly return undef from the method. - Boldra	[reply]
Re^2: return explicit undef - Best Practices? by SuicideJunkie (Vicar) on Dec 09, 2008 at 14:17 UTC
You could return 0 or '' for false instead, saving undef for actual errors.	[reply]