From: Martin D. <mar...@te...> - 2003-03-21 12:17:13
|
Andreas Poth a =E9crit: > I would perfer to keep arrays instead of list, because this seems to me= =20 > more flexible and faster (especially for larger geometries) than copyin= g=20 > lists to array and vice versa. Well, I tend to see exactly the opposite... List seems to me both more=20 flexible and faster than array, especially for larger geometries! Lets=20 me explain: - Returning an array is likely to requires a copy because: 1) The internal data structure may be different than the return type; 2) Even if the internal data structure matches, a good Java practice would requires a defensive copy. - Returning a java.util.List do not requires any copy at all, because List is an interface. The implementation doesn't have to be ArrayList. A good geometry implementation would returns a package-private List implementation with some knowledge of the geometry's internal data structure. The List would iterate directly in the geometry internal data, no matter how those data are organized, without the need for copying a whole array. - List provides all the array's functionalities plus a buch of usefull methods: contains, add, remove, insert, etc. (we don't have to support add, remove and insert if the geometry is immutable). - If the user really want an array, he can invokes List.toArray(). The 'keySet()' method in java.util.AbstractMap is a good example of such=20 an approach: http://java.sun.com/j2se/1.4.1/docs/api/java/util/AbstractMap.html#keySet= () It returns all keys contained in the Map. But it doesn't returns them as=20 an array (which would requires a copy since HashMap doesn't stores keys=20 in an array). Instead, it returns a special Set implementation wich is a=20 view of Map's keys. Absolutly no copy are performed. The means inconvenient of List is that we lost the type informations=20 (e.g. nothing tell us that a List contains DirectPosition elements).=20 Generic type in the upcomming J2SE 1.5 would solve very well this=20 problem. In my understanding, we are not allowed to introduce J2SE 1.5=20 dependencies in the GeoAPI interfaces. However, a compromise may be=20 possible: - The current javac prototype generates a byte code fully compatible with J2SE 1.2. If we use generic types in interfaces, the compilation would requires J2SE 1.5, but using it would not. Any client with J2SE 1.2+ would be able to use the generated JAR file without any problem. Since we do not expect user to recompile the JAR, it may not be an unacceptable compromise... - However, Sun seems to consider some byte code change for J2SE 1.5. We would need to check if we still have a way to compile J2SE 1.2 compatible code with generic types (maybe with a "-target 1.2" option). Of course, we would lost generic type benefict in the JAR file, but we still have the benefict for the JavaDoc. > Another point is the naming of accessor methods. In java they should=20 > have a prefix 'get' or 'is'. most interfaces haven't a clear strategy o= f=20 > using it (see GeometryRoot for example). I think this shall be handled=20 > uniformily (I perfer to have prefixes for all accessor and mutator=20 > methods). Agree. Regards, Martin. |