Marvin Froehlich:
I noticed that you created a new package com.xith3d.utility.lists containing a read-only list class:
https://xith3d.dev.java.net/source/browse/xith3d/src/com/xith3d/utility/lists/ROList.java?rev=1.1&view=auto&content-type=text/vnd.viewcvs-markup
Why not use java.util.Collections.unmodifiableList() instead?
http://java.sun.com/javase/6/docs/api/java/util/Collections.html#unmodifiableList(java.util.List)
I didn’t know this functionality, even though I have searched for it in the standard java. Thanks for the advice. I will switch to this one. The only problem is, that it won’t be compatible to Enumeration, so we will break the compatiblity a little bit. But I think, it should be ok (and better than a own-creation like mine).
I see that you just added ROList as a return value for a method in class View:
https://xith3d.dev.java.net/source/browse/xith3d/src/com/xith3d/scenegraph/View.java?r1=1.62&r2=1.63
Why?
If it’s ok (espeacially) for you, I can use this Collections.unmodifiableList method. But it won’t be compatible to the old interface. ROList implements Enumeration. So it is compatible to the old interface and I guess to Java3D. the Iterable Interface of a List is of a high value because you can more easily loop through it with nice java 5 loops. Well I don’t need this Enumeration implementation and I don’t think many people need it nor like it. So if it’s ok, fr you, I will use unmodifiableList.
Let’s just stick with the original Java 3D API method signature:
http://java.sun.com/products/java-media/3D/forDevelopers/J3D_1_3_API/j3dapi/javax/media/j3d/View.html#getAllCanvas3Ds()
No sense making dubious code optimizations where none is needed. Makes things easier for everyone. Minimizes developer time.
It is absolutely compatible to this signature, since ROList implements Enumeration, as I said. And Enumeration is legacy and just uncomforatble to use.
Don’t you want progress in the development. Enumeration is bad. But If you want to use the returned value like an Enumeration, you may do so. But if you want fast development time, you can and should make use of new language features like the java 5 loops. Compare the code needed to loop through an Enumeration to the one for an Itarable list. It’s much less and nicer code on the side of Iterable.
So this optimizatio is definitely needed and good and does minimize dev time. And ROList is no dubious code.
EDIT: And by the way: In this manner the old ListEnumeration class was dubious code, because there is a method in Collections called Collections.enumeration which does, what this class did.
I thought you said yourself that when you introduced ROList, you did not know about java.util.Collections.unmodifiableList()?
http://java.sun.com/javase/6/docs/api/java/util/Collections.html#unmodifiableList(java.util.List)
You should delete ROList from the Xith library so developers do not waste their time on it. Either go with something more standard, like unmodifiableList(), or just stick to the original Java 3D API return value.
I just thought of a couple of other good reasons for sticking to the Java 3D API:
OK, I made the following modifications:
I changed the method getAllLocales() to return an Enumeration. I really hope, you don’t think people will waste their time dicovering this magic change to the Java3D API concerning generics. This change is definitely good and necessary.
Next to this method I added one called getLocales returning a List created by Collections.unmodifiableList. And I deleted ROList because it is not needed anymore.
I did so for all the other places where ROList was used.
I think, this is fair, isn’t it.
Croft, consider this: Java3D doesn’t seem to be very well supported by sun and maybe they will drop support for it in the future, if I got you right. Should we really strickly stick to such an API but make valueable changes to it?