http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7417 --- Comment #18 from Jared Camins-Esakov <jcamins@cpbibliography.com> --- (In reply to comment #15)
(In reply to comment #14)
Chris, Thanks for your answer.
Which introduces no new dependencies Koha already use a lot of dependencies. For a dependency as much important part (OOP) I think it is not a good argument. Furthermore this dependency will be used elsewhere :)
and importantly it's fast Class::Accessor does not employ an autoloader Yes, I agree with you, fastness is one of the more important thing
thus it is much faster than you'd think. Its generated methods incur no special penalty over ones you'd write yourself. Ok cool. But it is just for accessor isn't it ? I think we will quickly want to add relations between our classes (roles, superclasses, etc.). Before introducing new important classes (as Authority) in the Koha namespace, I think it is important to start a global discussion. What do we want for this new namespace and for this rewriting ?
I think we want it to work, and provide much-needed features.
It would be great to have new classes written as we want from the beginning. This would show what are the best practices to follow for futures classes. To have a reflexion about how we want to rewrite the C4 modules seems to be the first step. How we want to order our classes ? What Koha::Authority must do ? We agree we don't want all C4::AuthoritiesMarc into Koha::Authority :)
We have been talking about this for a year, and no one actually seems to have much of an opinion, other than the concepts set down in the namespace RFC. As for what Koha::Authority does, I propose the following list: 1. Retrieve an authority from the database. 2. Update/create an authority in the database. 3. Retrieve metadata about the authority. 4. Set metadata about the authority. 5. There is no five.
Mo[o][se] module[s] permits to create classes (with attr, method, etc.), inheritance, etc. In fact it allows to do OO, very simply if an application design has been made before.
I don't think I see the benefit here. Don't get me wrong, I really like the idea of Moose, but the speed issue, and the errors every time I try to load it, make me think that we're better off using Class::Accessor, which we already use elsewhere in Koha to great success. -- You are receiving this mail because: You are watching all bug changes.