[Bioperl-l] Annotated.pm

Hilmar Lapp hlapp at gmx.net
Sat Nov 27 03:32:22 EST 2004

On Friday, November 26, 2004, at 11:45  PM, Allen Day wrote:

> On Fri, 26 Nov 2004, Hilmar Lapp wrote:
>> On Friday, November 26, 2004, at 11:06  PM, Allen Day wrote:
>>>> As an aside, your get_Annotations() short-cut is brittle. If someone
>>>> happens to add a second 'source' annotation (or any other tag for 
>>>> that
>>>> matter), it will break and return the length of the array instead of
>>> this is intentional and documented.
>> Maybe I'm missing something but I'm not sure why you would want code
>> that is brittle on purpose. Why would that help the end user?
> if you're not sure how many annotations there are, you'd better call 
> it in
> list context unless you want the count:
> my @value = $feature->get_Annotations('key1');
> my $count = $feature->get_Annotations('key1');

Well, as an implementation agnostic client $feature IS-A AnnotatableI 
and therefore you can't call $feature->get_Annotations but need 

But this is not what I meant. As an example, $annotated->source_tag() 
will delegate to source():

sub source_tag {
   return $shift->source(@_);

Annotated::source returns what the get_Annotations() short-cut returns:

   return $self->get_Annotations('source');

If somebody accidentally added another annotation with tag 'source', 
not knowing that it is being used internally, the next call to 
$annotated->source_tag() will return a number, not the source tag, and 
not an array of source tags.

This is what I mean by brittle. I mean that it is easy to hang yourself 
as a user and you don't even get a warning before you die. In this case 
it will even be a very slow death since a number is still a scalar, and 
in order to realize the problem you need to actually see that it is a 
number and not a meaningful string.

> but if you're sure there is only one, you can call it either way:
> my @value = $feature->get_Annotations('key2');
> my $value = $feature->get_Annotations('key2');
>>>> the first element. Furthermore, I wouldn't test for IS-A
>>>> Bio::Annotation::OntologyTerm - this is only an implementation class
>>>> and one day there may be better ones. What you really care about is
>>>> that the object IS-A Bio::AnnotationI (so that you can add it to the
>>>> collection) and IS-A Bio::Ontology::TermI (so that you have your
>>>> ontology-enforced typing).
>>> what class are you referring to here?
>> The one in the subject line.
> I don't see any lines with 'isa' that also contain
> Bio::Annotation::OntologyTerm.  Please be more specific.

The implementation of Annotated::type() has the following piece of code 
in it:

	# blah ...
     elsif(ref($val) && $val->isa('Bio::Annotation::OntologyTerm')){
       $term = $val;
     else {
       #we have the wrong type of object
       $self->throw('give type() a SOFA term name, identifier, or 
::OntologyTerm object, not '.$val);

This means that if I came up with another implementation class that 
adapts a TermI to an AnnotationI I'd be rejected by this code, even 
though my implementation semantically would perfectly fit the bill.


>> 	-hilmar
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l at portal.open-bio.org
> http://portal.open-bio.org/mailman/listinfo/bioperl-l
Hilmar Lapp                            email: lapp at gnf.org
GNF, San Diego, Ca. 92121              phone: +1-858-812-1757

More information about the Bioperl-l mailing list