https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29746 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |katrin.fischer@bsz-bw.de --- Comment #7 from Tomás Cohen Arazi <tomascohen@gmail.com> --- I've just renamed the class because this is not an attempt to introduce booleans in Perl :-D but a way to have a consistent way to return values and have them evaluated in the core codebase. I will pick a real-life example to highlight how it can be useful: CanItemBeReserved. This method is called like this: C4/Circulation.pm: @items = grep { CanItemBeReserved( ... )->{status} eq 'OK' } @items; In this case, the reason why it is not holdable doesn't really care. We are comparing to an arbitrary string that represents a boolean value (to be fair, OK is the obvious pick :-D, but the ->{status} bit could vary from one implementation to another). If it used this library as a return value, we would only evaluate the result in a boolean context: @items = grep { CanItemBeReserved( ... ) } @items; And if we wanted to know 'why', we could do: my $result_object = CanItemBeReserved( ... ); and then have a consistent way for this method and all other methods that need to return extra info: if ( !$result_object ) { foreach my $message ( @{$result_object->messages} ) { $template->param( do_your_thingy ); } } Please feel free to comment about this and add your thoughts. As this return value has its own class instead of what we did before, we could do things like: - implement a to_api() method that makes it render in a suitable way, have it embed the messages, etc. I can see how it can be useful. - some other caller contexts could be considered. for instance, some methods we have return, in list context, a boolean (the result) and a payload with extra info. We could make this class do the same, for an easy transition of legacy code. -- You are receiving this mail because: You are watching all bug changes.