[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