Referring to the dev meeting and bug 22407, I propose the following rewording: PERL15 Using Koha::Object[s] PERL15(a) Code added to the Koha:: namespace should be object-oriented unless there is a very good reason to do otherwise. In that case the reason should be documented clearly. PERL15(b) Code in Koha::Object[s] should normally not refer back to C4. Obviously, this cannot be enforced harshly until the refactoring has been completed. PERL15(c) Use DBIC relations to (pre)fetch a related Koha object rather than searching it explicitly. (See bug 22407) PERL28 Other object oriented code guidelines (in addition to PERL15) I think we need to move the Accessor and idiom for -> new rules from PERL15 to another rule. I opened rule 28 for that depending on discussing the following: Class::Accessor is a great way to provide access to member variables. => My suggestion would be to remove this rule. It is true but we do not say that it is the only way to do it. (We are not even using Class::Accessor in Koha objects.) Or just say PERL28(a) To provide access to member variables, there are several ways including but not limited to using Class::Accessor. A useful idiom for the ->new() routine in object-oriented classes that do not need to process the arguments passed in as a hashref but merely need to save them for future processing => This suggestion is fine. It says use a parameter hash for sub new. We normally do that. Reworded: PERL 28(b) Use a hashref as second parameter in sub new when passing arguments. Any feedback? Marcel Museumstraat 1 Postbus 74888 1070 DN Amsterdam Rijksmuseum.nl Nu te zien: Operatie Nachtwacht Verwacht: Caravaggio-Bernini. Barok in Rome Dankzij Waller 2010-2020 T/m 18 jaar gratis Please think before you print
Ooops, I forgot to reply to this. It looks good to me Marcel. *Martin Renvoize* <https://www.ptfs-europe.com> Development Team Manager Community Release Manager (19.11, 20.05) *Phone:* +44 (0) 1483 378728 *Mobile:* +44 (0) 7725 985 636 *Email:* martin.renvoize@ptfs-europe.com *Fax:* +44 (0) 800 756 6384 www.ptfs-europe.com Registered in the United Kingdom No. 06416372 VAT Reg No. 925 7211 30 The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this email message in error, please email the sender at info@ptfs-europe.com On Wed, 29 Jan 2020 at 16:25, Marcel de Rooy <M.de.Rooy@rijksmuseum.nl> wrote:
Referring to the dev meeting and bug 22407, I propose the following rewording:
PERL15 Using Koha::Object[s] PERL15(a) Code added to the Koha:: namespace should be object-oriented unless there is a very good reason to do otherwise. In that case the reason should be documented clearly. PERL15(b) Code in Koha::Object[s] should normally not refer back to C4. Obviously, this cannot be enforced harshly until the refactoring has been completed. PERL15(c) Use DBIC relations to (pre)fetch a related Koha object rather than searching it explicitly. (See bug 22407)
PERL28 Other object oriented code guidelines (in addition to PERL15) I think we need to move the Accessor and idiom for -> new rules from PERL15 to another rule. I opened rule 28 for that depending on discussing the following: Class::Accessor is a great way to provide access to member variables. => My suggestion would be to remove this rule. It is true but we do not say that it is the only way to do it. (We are not even using Class::Accessor in Koha objects.) Or just say PERL28(a) To provide access to member variables, there are several ways including but not limited to using Class::Accessor.
A useful idiom for the ->new() routine in object-oriented classes that do not need to process the arguments passed in as a hashref but merely need to save them for future processing => This suggestion is fine. It says use a parameter hash for sub new. We normally do that. Reworded: PERL 28(b) Use a hashref as second parameter in sub new when passing arguments.
Any feedback?
Marcel [image: http://www.rijksmuseum.nl] <http://www.rijksmuseum.nl/>
Museumstraat 1 Postbus 74888 1070 DN Amsterdam *Rijksmuseum.nl* <http://www.rijksmuseum.nl/> Nu te zien: *Operatie Nachtwacht* <https://www.rijksmuseum.nl/nl/nachtwacht> Verwacht: *Caravaggio-Bernini. Barok in Rome* <https://www.rijksmuseum.nl/nl/caravaggio-bernini> *Dankzij Waller 2010-2020* <https://www.rijksmuseum.nl/nl/nu-in-het-museum/tentoonstellingen-verwacht/dankzij-waller-2010-2020>
T/m 18 jaar gratis
Please think before you print _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org https://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/
Hi Marcel, Sorry for the late reply. All looks ok to me as well, only a couple of things: 15b: better to point to C4 than c/p code from there to Koha :) Ideally the code should be moved to Koha, then used from there. But no always a solution I guess. 15c: On 22407 comment 3 I listed the different cases of the relationship, and how we should use them. ie. no "return unless" if not necessary, etc. I think they could be copied to the wiki as an example to follow https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22407#c3 And a question about 15a, what could be a good reason to not use OOP in Koha? Thanks! Jonathan Le mer. 29 janv. 2020 à 17:24, Marcel de Rooy <M.de.Rooy@rijksmuseum.nl> a écrit :
Referring to the dev meeting and bug 22407, I propose the following rewording:
PERL15 Using Koha::Object[s] PERL15(a) Code added to the Koha:: namespace should be object-oriented unless there is a very good reason to do otherwise. In that case the reason should be documented clearly. PERL15(b) Code in Koha::Object[s] should normally not refer back to C4. Obviously, this cannot be enforced harshly until the refactoring has been completed. PERL15(c) Use DBIC relations to (pre)fetch a related Koha object rather than searching it explicitly. (See bug 22407)
PERL28 Other object oriented code guidelines (in addition to PERL15) I think we need to move the Accessor and idiom for -> new rules from PERL15 to another rule. I opened rule 28 for that depending on discussing the following: Class::Accessor is a great way to provide access to member variables. => My suggestion would be to remove this rule. It is true but we do not say that it is the only way to do it. (We are not even using Class::Accessor in Koha objects.) Or just say PERL28(a) To provide access to member variables, there are several ways including but not limited to using Class::Accessor.
A useful idiom for the ->new() routine in object-oriented classes that do not need to process the arguments passed in as a hashref but merely need to save them for future processing => This suggestion is fine. It says use a parameter hash for sub new. We normally do that. Reworded: PERL 28(b) Use a hashref as second parameter in sub new when passing arguments.
Any feedback?
Marcel [image: http://www.rijksmuseum.nl] <http://www.rijksmuseum.nl/>
Museumstraat 1 Postbus 74888 1070 DN Amsterdam *Rijksmuseum.nl* <http://www.rijksmuseum.nl/> Nu te zien: *Operatie Nachtwacht* <https://www.rijksmuseum.nl/nl/nachtwacht> Verwacht: *Caravaggio-Bernini. Barok in Rome* <https://www.rijksmuseum.nl/nl/caravaggio-bernini> *Dankzij Waller 2010-2020* <https://www.rijksmuseum.nl/nl/nu-in-het-museum/tentoonstellingen-verwacht/dankzij-waller-2010-2020>
T/m 18 jaar gratis
Please think before you print _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org https://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)
-
Jonathan Druart -
Marcel de Rooy -
Renvoize, Martin