[Biojava-l] Basis and Atomic Symbols
Wed, 07 Mar 2001 12:13:05 +0000
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.
> Biojava-l mailing list - Biojavaemail@example.com