We now have a few of 'get_marc_*' accessors in Koha::Biblio, but their returns are really inconsistent.
I feel like we aught to try and make them as consistent as possible so future developers can use them without having to dig through the code to see what they return.
In `get_marc_notes` we return an array of note strings from the marc record.. these may be selective subfield concatenations and could be in various orders.
In `get_marc_host` we return either a Koha::Biblio object or the Biblio object + the subfield g, as a string, from the current records marc21 773 field we used to find the host.
In `get_marc_components` we return an array of MARCXML strings.
I think we could do better here.. certainly with the `_components` and `_host` routines either consistently returning Koha::Biblio/Koha::Biblios or MARCXML string/strings for example. As for `get_marc_notes`, this is a little different.. we could possibly return an array of MARC::Field objects for later processing, or perhaps we aught to have a second naming scheme for returning strings from MARC/Metadata vs retuning a marc/metadata object/string itself?
On first look.. I feel like 'MARCXML' strings or 'MARC::Record' objects would be the right thing to return from the `get_marc_` accessors.. and then the consumer uses this response to do the next thing.. be that parse the string with XSLT for display, or get the Koha::Biblio using the data within.. I suggest this as it's what's returned from the search engine used for the two existing calls and thus reduces reduces further calls internally that may not be required.
As for get_marc_notes.. perhaps we would be better going back to 'get_notes' or 'get_notes_from_marc' to set a distinction between 'something that returns a MARC thing' and 'something that returns string/s from inside the MARC'