[Koha-bugs] [Bug 19809] Koha::Objects::find calls do not need to be forbidden in list context
bugzilla-daemon at bugs.koha-community.org
bugzilla-daemon at bugs.koha-community.org
Wed Nov 6 16:39:53 CET 2019
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19809
--- Comment #21 from Julian Maurice <julian.maurice at biblibre.com> ---
(In reply to Jonathan Druart from comment #20)
> From 18539:
> """
> Reading https://perlmaven.com/how-to-return-undef-from-a-function
> this sound like the more correct behaviour.
> """
All the pages I read about this topic talk about returning undef to indicate a
failure (it is compared to `die` and `croak`)
But this is not a failure here. Not finding a database entry is not a failure.
"No results" is a valid result.
https://perlmaven.com/how-to-return-undef-from-a-function uses this example
my @y_results = div(42, 0);
if (@y_results) {
say "Success! We can divide 42 by 0";
} else {
say "Failure!";
}
In my opinion this is a bad example. Nobody should write code like that. The
`div` subroutine must be clear about its return value. It is then the caller
responsibility to use it correctly.
And there is nothing wrong in calling `div` in a list context. For example:
my @results = map { div(42, $_) } (0..9);
Forbidding a perfectly valid use case makes no sense to me.
> I am not against another one, but what would be the gain?
It just feels like the sane thing to do. I expect Koha::Objects->find to return
a scalar value, not a list. And adding `scalar` in front of `->find` calls
seems superfluous.
If I'm the only one feeling that way, please mark it as "wontfix", I will
gladly give up on this patch
--
You are receiving this mail because:
You are watching all bug changes.
More information about the Koha-bugs
mailing list