[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[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


NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.