<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Sep 11, 2014 at 3:31 AM, Jonathan Druart <span dir="ltr"><<a href="mailto:jonathan.druart@biblibre.com" target="_blank">jonathan.druart@biblibre.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>2014-09-11 2:39 GMT+02:00 Kyle Hall <<a href="mailto:kyle.m.hall@gmail.com" target="_blank">kyle.m.hall@gmail.com</a>>:<br>
> On Wed, Sep 10, 2014 at 5:00 AM, Jonathan Druart<br>
> <<a href="mailto:jonathan.druart@biblibre.com" target="_blank">jonathan.druart@biblibre.com</a>> wrote:<br>
>><br>
>> Hi all,<br>
>><br>
>> IMO a ResultSet should not be instantiate in a pl script for some<br>
>> reasons (I already listed yesterday, nothing new :))<br>
>> - should be unit tested<br>
>> - easier to maintain<br>
>> - easier to reuse<br>
>><br>
>> But I don't think it's a big deal.<br>
><br>
><br>
> I agree with all these principles, and none of them conflict with what I am<br>
> proposing. Result and ResultSet methods are no different than C4/Koha<br>
> methods and subroutines.<br>
<br>
</span>Yes they are, as Robin said, It is an API for the DB, not for the<br>
functional job.<br></blockquote><div><br></div><div>Again, only if we treat it that way. We can leverage DBIC to add formality and commonality to our OO code where it's always been bespoke implementations previously.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span><br>
>> Please comment this part of code and share yours!<br>
><br>
> Can you see how this gives no advantage, but simply wraps the useful code in<br>
> another layer of abstraction? There simply is no advantage to doing this. In<br>
> the long run this type of thinking will make things more complicated and<br>
> more error prone than they need to be.<br>
<br>
</span>The advantage is to share responsabilities, which is already a lot.<br></blockquote><div><br></div><div>I don't understand your comment.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span><br>
> Instead of all this code we simply need to add one method to<br>
> Result::Borrower. Here is the gist of it:<br>
><br>
> sub is_debarred {<br>
>     my ( $self ) = @_;<br>
>     return $self->debarred_date() > dt_from_string();<br>
> }<br>
><br>
> Think about all the overhead and complexity that is removed by this<br>
> variation.<br>
<br>
</span>I don't understand where is the complexity. We need Koha::Module<br>
packages. We cannot put all our code into<br>
Koha::Schema::Result::Module.<br>
Why everyone is afraid of abstraction layers?<br>
</blockquote></div><br></div><div class="gmail_extra">We *don't* need Koha::Module packages for everything! My point is that DBIC provides us with an abstraction layer already! Wrapping a DBIC class in another class provides no advantage and just obfuscates our code, increases hardware requirements, and leaves more room to introduce bugs. If we are just going to use DBIC  to avoid writing direct sql queries, we should be using something like Fey instead.</div><div class="gmail_extra"><br></div><div class="gmail_extra">We are a collective of developers with many different styles and opinions. We often have very different approaches to how we implement new features. If we go down this path of wrapping DBIC in another abstraction layer, we simply continue down this patch of having many different bespoke implementations. If we use dbic as our abstraction layer, we remove much of that issue.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Kyle</div><div class="gmail_extra"><br></div></div>