Hi developers,
I stumbled upon a line of code recently and I can't figure out why it
has be done this way. I hope you can help me :)
The line in question is in Koha::Objects::find:
croak 'Cannot use "->find" in list context' if wantarray;
I read the two bugs (18539 and 18179) and the link g
Find is supposed for retrieving one result not multiple ones. Use search
instead.
Using find in a list context is not correct.
Van: koha-devel-boun...@lists.koha-community.org
namens Julian Maurice
Verzonden: woensdag 13 december 2017 14:34:07
Aan: koha-devel
I know that find is supposed to retrieve only one result. That's why we
shouldn't have to care about the context, it's never ambiguous.
I should be allowed to write
push @patrons, Koha::Patrons->find($borrowernumber);
without specifying that I only want one record (using 'scalar')
Le 13/12/2
Hello all,
Is there someone using Koha with ES in production ?
bywater, PTFS-E, Catalyst-NZ, Theke, or any other support company,
what's your plan ?
BibLibre is planning to invest some effort to work on Koha-ES with
UNIMARC in the next months, if there are things to share, we would be
more
Hi Julian,
> @a = Koha::Patrons->find('foo'); # would result in @a = (undef)
And that leads to issues:
if ( @a ) { # = 1
say $a[0]->borrowernumber; # BOOM
}
See also https://perlmaven.com/how-to-return-undef-from-a-function (was it
the link you were talking about?)
Cheers,
Jonathan
On Wed,
Ok, but the proposed fix doesn't fix this code:
@a = scalar Koha::Patrons->find('foo');
if (@a) { # still equals to 1
say $a[0]->borrowernumber; # still BOOM
}
And yes, that was the link ;)
Le 13/12/2017 à 14:58, Jonathan Druart a écrit :
> Hi Julian,
>
>
>> @a = Koha::Patrons->find('foo');
Probably, but that's not my point.
I understand why the previous code needed to be fixed, which is to avoid
that
{ a => Koha::Patrons->find("foo"), b => "bar" }
would result in { a => "b", "bar" => undef }
My question is: why the solution to this problem was to forbid calls in
list context whil
On 13. des. 2017 15:56, Julian Maurice wrote:
My question is: why the solution to this problem was to forbid calls in
list context while we could simply return an explicit undef?
It forces us to write 'scalar' in front of a call that should always
return a single value, and in my opinion it's a "
Is anyone currently working on, or have plans to work on Bug 19736,
"Add a digest option for AUTO_RENEWALS Notice?"
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19736
-- Owen
--
Web Developer
Athens County Public Libraries
http://www.myacpl.org
___
Alternatively, you could write:
my $foo = Koha::Patrons->find("foo");
my $hashref = { a => $foo, b => "bar" };
or
my $foo = Koha::Patrons->find("foo");
my $hashref = { b => "bar" };
$hashref->{a} = $foo if $foo;
Personally, I'm not a fan of putting function calls in data structures.
David Coo
I'm collecting news for the December newsletter. Send anything
noteworthy to:
k o h a news AT gmail dot com
News criteria:
---
** For events **:
- Please include dates for past events. If I can't find dates I may
not add it.
- Announcements for future events with
11 matches
Mail list logo
