[Biojava-l] Basis and Atomic Symbols

Matthew Pocock mrp@sanger.ac.uk
Wed, 07 Mar 2001 12:13:05 +0000

Hi Mark,

Just by way of observation, we have found that instanceof is vastly more 
time-efficient in a range of VMs than catching ClassCastException. This 
is because the memory churn/introspection cost associated with building 
the stack-trace data structures is huge compared to taking the class for 
an object and seing if it is assignable to some other class (I think 
this just involves walking through a few parent class pointers).

The alphabet implementations and AlphabetManager together synergise to 
make sure that symbol instances implement the most specific interface 
that they can. The code is a bit hairy - uses lots of double- and 
tripple-binding - but it should ensure that if you try to make a 
BasisSymbol such as ata that in fact it constructs an instance of 
AtomicSymbol (which is a sub-interface of BasisSymbol) for you. If you 
find any case where this is not happening, then this is a bug. All this 
stuff should be accessed client-side using:

	Symbol getAmbiguity(Set symbolSet)
	Symbol getSymbol(List symbolList)

and then checking the interface implemented by the returned symbol 
against Symbol, BasisSymbol and AtomicSymbol. Most of the time, you can 
get away with not checking.


>>> Alternatively if a basis symbol is actually non-redundant 
>> can this be
>>> determined and is there a way to convert it to an Atomic 
>> Symbol (casting is
>>> not allowed).
>> A non-ambiguous basis symbol (I take it this is what you
>> mean by non-redundant) IS an atomic symbol.  The behind-the-scenes
>> Symbol construction code in AlphabetManager and friends should
>> ensure that this is the case.  You can check with instanceof
>> This doesn't avoid the need for a cast, though.  What is the
>> problem with casting?
> Actually there wasn't a problem with casting per se I just needed to
> sensibly deal with the basis symbol objects by catching ClassCastExceptions
> or via your idea of using instanceof.
> Thanks
> Mark
> _______________________________________________
> Biojava-l mailing list  -  Biojava-l@biojava.org
> http://biojava.org/mailman/listinfo/biojava-l