http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11319
--- Comment #4 from Jonathan Druart <[email protected]> --- (In reply to Kyle M Hall from comment #3) Kyle, Thank you for your feedback. > As a POC, it looks pretty good to me! The only suggestion I would have would > be not keep the export for read_field, and modify that sub to check for a > value in the subfield value. That is, instead of having read, read_field, > and read_subfield, keep all the code in read_field and just do an > if/then/else. That way the exported name is still read_field, and thus > doesn't change the API. This way, I am afraid that routines like copy_field and update_field will be really big. It's why I think it would be better to split them. > It's entirely possible for SimpleMARC to be used in custom scripts, so > adding to the API is fine, but removing/renaming api subs should be avoided. > I know that such an occurence is unlikely at this point, but even in the > future it will confuse users to have update_field, copy_field, move_field, > read, and delete. It just breaks the naming convention. Yes of course, but as I said, this patch only implements the read and delete routines. The goal is to do the same work for all other subroutines in the SimpleMarc module (update_field, copy_field, move_field). > The other option would be to remove "_field" from all the subroutines. I > have no problem with either choice. Let's just keep the convention > standardized! Maybe should we only keep a call to delete_field which will call either the private _delete_field or _delete_subfield routines depending on the subfield value. Like that, we would not have to change the API. -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
