2014-09-11 2:39 GMT+02:00 Kyle Hall <kyle.m.hall@gmail.com>:
On Wed, Sep 10, 2014 at 5:00 AM, Jonathan Druart <jonathan.druart@biblibre.com> wrote:
Hi all,
IMO a ResultSet should not be instantiate in a pl script for some reasons (I already listed yesterday, nothing new :)) - should be unit tested - easier to maintain - easier to reuse
But I don't think it's a big deal.
I agree with all these principles, and none of them conflict with what I am proposing. Result and ResultSet methods are no different than C4/Koha methods and subroutines.
Yes they are, as Robin said, It is an API for the DB, not for the functional job.
Please comment this part of code and share yours!
Can you see how this gives no advantage, but simply wraps the useful code in another layer of abstraction? There simply is no advantage to doing this. In the long run this type of thinking will make things more complicated and more error prone than they need to be.
The advantage is to share responsabilities, which is already a lot.
Instead of all this code we simply need to add one method to Result::Borrower. Here is the gist of it:
sub is_debarred { my ( $self ) = @_; return $self->debarred_date() > dt_from_string(); }
Think about all the overhead and complexity that is removed by this variation.
I don't understand where is the complexity. We need Koha::Module packages. We cannot put all our code into Koha::Schema::Result::Module. Why everyone is afraid of abstraction layers?