[Biojava-dev] The future of BioJava

[Andy Yates]

That's fair enough & spot on what generics are intended for. Also means 
if someone wanted to allow any symbols in it's easy enough to use:

<T extends Symbol> void doSomething(List<T> symbols);

I've only ever need to know what T was once & the easiest way around it 
is as you've said to check the first element of an input collection or 
to take in a class & use generics to enforce the correct class type i.e.

<T> T getGenericType(Class<T> clazz);

String output = getGenericType(String.class);	//This is ok
String output = getGenericType(Long.class);	//This won't compile

I'd say so long as 'dodgy' things are refactored out to helper classes 
then they can change as & when better solutions come along. A good 
example of this is Spring's synchronized map builder which at runtime 
will attempt to figure out what is available on the classpath and then 
return a map which will provide the best syncrhronized performance (for 
example if it's a pre 1.5 jdk it'll return a normal synchronized map 
otherwise it'll use ConcurrentHashMap).

Andy

Richard Holland wrote:
> -----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-----