Hi the list, Just reading Frédéric thoughts about Moose & Moo written on bug 11190. For those who missed the IRC dev meeting yesterday, this bug was discussed yesterday : http://meetings.koha-community.org/2015/development_irc_meeting_15_april_201... I don't know which decision we must take, but I strongly think that we must all read Frédéric arguments. Maybe Moo/Moose was a good decision, maybe not. Anyway, there are not so many scripts using Moo/Moose, so we can stil change our minds. Next steps ? I'd like to have more informations. For example: * arguments in favor of Moo ? * is the argument "the overhead is cancelled by Plack persistency" valid & is it removing this argument in favor of Moo ? * I'd like to have more details about "too many important features are lost" with Moo ? *Comment # 36 <http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11190#c36> on bug 11190 <http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11190> from Frédéric Demians <mailto:frederic@tamil.fr> * Few personal notes about Moose vs Moo (just seen IRC dev meeting logs): There is an overhead using Moose for small short lived programs. But for long- running cronjob/maintenance scripts, there isn't any problem using Moose. For Koha WUI scripts, Moose start time is a problem as long as Koha operates in CGI mode. As soon as there is persistence (Plack), it isn't a problem anymore. This issue of runtime penaly due to using a large and complex library, doing a lot of stuff behind the scene, is not different with Moose and DBIx::Class I don't say DBIx::Class is bad. Moose it bad too => So let's go with Moose! I'd say both libraries share a lot of good things. I think that Moose has various advantages over other OO frameworks. It's complete, very well documented, widely used, a standard, carefully packaged for all major Linux distro. All books about the so-called "modern-Perl movement" deals with using Moose as OO. There is the Perl's famous moto: There's more than one way to do it. Applied to OO, this could conduct to chaos. There are so many ways to do OO in Perl. Code become unreadable and unreliable. Moose forces to adopt a proper and consistent OO approach. Moo try to solve a non-issue (library weight, startup time) in modern execution environments at high price: too many important features are lost. -- Paul Poulain, Associé-gérant / co-owner BibLibre, Services en logiciels libres pour les bibliothèques BibLibre, Open Source software and services for libraries
Thanks Paul for raising this.
I'd like to have more informations. For example: * arguments in favor of Moo ?
Taking a look at Moo, its main advantages are speed and compatibility with Moose. https://metacpan.org/pod/Moo#MOO-AND-MOOSE
is the argument "the overhead is cancelled by Plack persistency" valid & is it removing this argument in favor of Moo ?
Don't forget that overall run-time performance of Koha is generally not limited by the object system, but by external IO, design decisions etc., AND persistency for a webapp. For the sitemap command-line script, I've compared execution time between Moose/Moo versions, and found: Moose ---------------- real 0m5.277s user 0m5.136s sys 0m0.096s Moo ---------------- real 0m4.705s user 0m4.540s sys 0m0.096s Moo is quicker but not that much in this case.
I'd like to have more details about "too many important features are lost" with Moo ?
Out of my brain, missing Moose features in Moo: - 'isa' parameter to attributes, and a complete type system. - Method modifiers, but is seems it's now somehow implemented in Moo. - Delegation - MooseX:: An extensive ecosystem of Moose extensions. - Class::MOP. A Meta Object Protocol. It allows to do classes introspection for example, or classes loading during runtime.
Hello all, Last call, if you have any concerns about the integration of Moo into Koha, please protest now. 2015-04-17 8:17 GMT+01:00 Frédéric Demians <frederic@tamil.fr>:
Thanks Paul for raising this.
I'd like to have more informations. For example: * arguments in favor of Moo ?
Taking a look at Moo, its main advantages are speed and compatibility with Moose.
https://metacpan.org/pod/Moo#MOO-AND-MOOSE
is the argument "the overhead is cancelled by Plack persistency" valid & is it removing this argument in favor of Moo ?
Don't forget that overall run-time performance of Koha is generally not limited by the object system, but by external IO, design decisions etc., AND persistency for a webapp.
For the sitemap command-line script, I've compared execution time between Moose/Moo versions, and found:
Moose ---------------- real 0m5.277s user 0m5.136s sys 0m0.096s
Moo ---------------- real 0m4.705s user 0m4.540s sys 0m0.096s
Moo is quicker but not that much in this case.
I'd like to have more details about "too many important features are lost" with Moo ?
Out of my brain, missing Moose features in Moo:
- 'isa' parameter to attributes, and a complete type system.
- Method modifiers, but is seems it's now somehow implemented in Moo.
- Delegation
- MooseX:: An extensive ecosystem of Moose extensions.
- Class::MOP. A Meta Object Protocol. It allows to do classes introspection for example, or classes loading during runtime. _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
participants (3)
-
Frédéric Demians -
Jonathan Druart -
Paul Poulain