[Biojava-dev] The future of BioJava

[Richard Holland]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

For our purposes we'd use them to restrict valid input to a method - so
that if the user tries to write a program which passes in
List<RNASymbol> to a method which only takes List<DNASymbol> it'll throw
a wobbly at compile time. The methods would include the type in their
signature and therefore only accept lists of that type.

We'd obviously have to be careful with method naming as you point out -
i.e. no overloading methods with different generic types of the same
parameters.

The bit about not being able to work out what T is is a pain indeed, but
I don't think we'd need to use that. In most cases it can be solved
hackily - whenever Sun produces a proper way of doing it we'd use it of
course. (Hacky solution: If passed List<T>, then do an instanceof
list.iterate().next() to find out type of first item in list, thus
implying the type of everything else in the list, assuming list is not
empty).

cheers,
Richard


Andy Yates wrote:
>> Also could we make SymbolList implement List? The iterator() method
>> would then do the cached conversion if required before returning an
>> Iterator<Symbol> over the symbols. That would make it very pluggable.
>> We'd need it to have a settable flag indicating whether the user wants
>> 1-indexed or 0-indexed access (the default being 1-indexed as this is
>> the most common biological use).
> 
> The important part of the 1.5 api is Iterable<T> which can be applied to 
> any class. It just means it will return an iterator & can be used in the 
> new foreach loop construct.
> 
>> Only downside is that List uses generics and so SymbolList must too -
>> meaning that SymbolList must always be declared as SymbolList<Symbol>
>> (or some subclass of Symbol).
>>
>> But that's also an upside - you could subclass Symbol into DNASymbol,
>> RNASymbol, etc. etc. - meaning that an alphabet is tied directly to the
>> symbol and need not be specified separately:
>>
>>   SymbolList<DNASymbol> dna = new SymbolList<DNASymbol>();
>>   dna.add(RNAAlphabet.Q); // Throws standard List exception!
>>
>>   SymbolList<CompoundSymbol<DNASymbol,ScoreSymbol>> = new ....; // Cool!
>>
>> Also cool is that you could do this:
>>
>>   public SymbolList<RNASymbol> translate(SymbolList<DNASymbol> dna);
>>       // Also cool!
> 
> Two problems with using generics that I've encountered:
> 
> 1). getSomething(SymbolList<DNASymbol> list); & 
> getSomething(SymbolList<RNASymbol> list); as far as the compiler is 
> concerned are the same method. Both take in an instance of SymbolList 
> (remember that generics are a list minute bolt-on to the JDK 1.5 API and 
> it really shows).
> 
> 2). It is impossible to infer the type of a generic i.e.
> 
> public <T> void doSomething(T genericObject) {
> 	if(T.equals(String.class)) {
> 		//Do something
> 	}
> }
> 
> This T type is ... well magical. It exists but it doesn't.
> 
> Anyway just be careful with generics. They save a lot of time & effort 
> but get too involved (or think they can solve everything like I did for 
> a short period) they're going to burn you badly or drive you mad for 1/2 
> a day wondering why javac claims something you've written is bogus.
> 
> Andy
> _______________________________________________
> biojava-dev mailing list
> biojava-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/biojava-dev
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG85U34C5LeMEKA/QRAl3pAKCFC6HBv5iXmGVKpuTwJQiwWuoMmwCdG/g2
ILxIABP6me8pfY995/e6A5M=
=a+oW
-----END PGP SIGNATURE-----