GitLab

On the one hand there seems to be no good reason for a MicroRNA object
having multiple arm attributes, on the other hand simply taking the
first one in the event of it happening may not even return the same
value every time (it depends on a lot of factors, from the
implementation details of AttributeAdaptor up to and including the
underlying database system). There was a warning but who reads those
anyway. Just throw an exception instead, if someone decides to allow
such a case they can always catch it.

There is now a dedicated class, Utils::RNAProductTypeMapper, which
provides type_id<->class_name mappings to both RNAProduct constructor
(with the side bonus of no longer having to set the type ID in the
constructor of each subclass) and RNAProductAdaptor. The latter will
likely be used more frequently than the former, therefore the default
map uses type IDs as keys; the reverse map is only generated the first
time it is needed.

In addition to the constructor, the RNAProductTypeMapper.pm defines a
function called mapper() which provides a singleton instance of the
mapper object.

The mappings are hardcoded instead of being retrieved from the database
because the latter could in principle result in execution of arbitrary
code.

Some tests have been defined as well.

1. List of arguments passed to the constructor now references the
superclass (a'la Feature class hierarchy) instead of listing them
explicitly.

2. Arm documentation now correctly lists values this property can take.

A minimal extension of Bio::EnsEMBL::RNAProduct, with the only new
information being the arm of the hairpin the miRNA has come from. On the
storage side, this information is stored as a new type of rnaproduct
attribute.