[netCDFJava #KSI-560385]: Generics in ucar.ma2

New Client Reply: Generics in ucar.ma2

Dear John,

I read your e-mail and thought about it. 

So to start with, the idea of Generics is to avoid 'runtime-typing' like casts 
and reflections (getclass()) and let the compiler check as much types as 
possible. 100% type safety is guaranteed then.
The tutorial http://java.sun.com/j2se/1.5/pdf/generics-tutorial.pdf is good and 
explaining how to integrate generics into old code/APIs, too. I think you 
better read it twice.

It is a disadvantage that arrays in Java are 'covariant', i.e. Object [] is a 
real superclass of String [].
That is from a generic point of view not correct since e.g.:
Object[ ] objArr;
String[ ] strArr = new String[10]; 
objArr = strArr; // 
objArr[0] = new Integer(5); //loss in information by this assignment but more 
important: apparently sufficient information (int > obj) for this assignment
String string = strArr[0]; //runtime exception! strArr[] returns a Integer

To understand this one has to think in terms of "write-access" and 
"read-access" on objects.
If you have an  Object[] objArr its ok to write some subtype into it: objArr[0] 
= new Integer(5).
But it is NOT ok to read a subtype from it: int test = objArr[0].

This idea is not only true for a single assignments but for complete methods. 
Imagine a generic method (a method with generic object as argument):
 - which only reads from the generic type, e.g. from 'number', then calling 
this method with a Float as argument instead of a Number is ok, too. You should 
declare it with <? extends Number>.
- On the other side, if a method is write Numbers (e.g. adds into an array of 
Numbers) this will not work for Floats but maybe for Objects, so you can write 
<? super Number>.
This is called bounded wildcards (compare 4.1).
Because arrays are covariant and a contradiction to invariant generic objects 
it is unfortunately not allowed to make a generic array (of doubles, ints, 
floats whatever): T[] genericArray = new T[]; 
I think the thousand lines of ucar.ma would reduce to rather one then 

Yet, I think there are a lot of possibilities in ucar.ma where it is possible 
to use generics. 

Make a new generic Class <T> Array
Hold in this class empty arrays float [], short [], long [] etc.
In constructor reflect type T.getclass() and initialize corresponding array .

Another point is the dimensionality of the matrices. First of all, I wonder 
that you are not making use of any 'final' statements. I think you should use 
them whenever possible to improve performance. And then I wonder why you have 
implementation D0..D7 and not just use an access-method with loops over their 
dimensions. A constructor Array(<T>, int d) would initialize the final 
dimension.

And then the most delicate part has to be implemented, think about all the 
methods, which parts of them are necessary (for example, I would prefer 
omitting the getDouble(), getFloat() methods etc) and replace it by getValue(), 
according to the initialized Array<T>), whenever there is something 
type-specific in the code it probably can be replaced by T or ?.

After all I would implement a new version with probably different API and 
deprecate the old one. I hope that you are not frightened and think about it. 
Letting the compiler do as much type-checking as possible is not a bad idea. 
Maybe the code can be also reduced a lot.
If you thought about it a while , please let me know!

Best regards,
Georg





-----Ursprüngliche Nachricht-----
Von: Unidata netCDF Java Support [mailto:address@hidden] 
Gesendet: Freitag, 19. August 2011 18:12
An: Steidl, Georg
Betreff: [netCDFJava #KSI-560385]: Generics in ucar.ma2


Hi Georg:

As you can tell, the Array classes preceded java generics. I use them wherever 
I can, but I dont understand them deep enough to actually write classes that 
implement them.

So the short answer is i'd love to have you contribute to that. However, I 
would guess that it would be hard to make this backwards compatible (?) If so, 
I would have to think carefully about how/if we could do this, or if we would 
need to make a new version with a different API.

What do you think?

John

> Hello NetCDF-Developers!
>
> I am really glad that there are projects like NetCDF-Java that you have
> created.  Since I got more familiar with Java Generics now I thought
> whether you think about implementing ucar.ma2 and all the Array Stuff
> with templates.
>
> Is there something planned? If yes, I would like to contribute to that.
>
> Regards,
> Georg Steidl
>
> --
> M.Sc. Comp. Engineering
>
> Deutsches Zentrum für Luft- und Raumfahrt e. V.  |   German Aerospace Center
> Institut für Aerodynamik und Strömungstechnik    |   Institute of 
> Aerodynamics and Flow Technology
> Abteilung Hubschrauber                        |   Department Helicopters
>
> Lilienthalplatz 7, 38108 Braunschweig, Germany
> Tel : +49 (0)531 295 3306
>
>
>

Ticket Details
===================
Ticket ID: KSI-560385
Department: Support netCDF Java
Priority: High
Status: Open



Ticket Details
===================
Ticket ID: KSI-560385
Department: Support netCDF Java
Priority: High
Status: Open
Link:  
https://www.unidata.ucar.edu/esupport/staff/index.php?_m=tickets&_a=viewticket&ticketid=18590


Ticket Details
===================
Ticket ID: KSI-560385
Department: Support netCDF Java
Priority: High
Status: Open