Andrea had a good idea today (well most days). He points out that nobody has implemented FeatureList properly yet ... and wonders if we can just return a FeatureCollection.
Thinking ... What do you guys think about making a SortedFeatureCollection -ie just the assurance that the iterator is sorted in some fashion. Specifically I am thinking of something like (http://java.sun.com/j2se/1.4.2/docs/api/java/util/SortedMap.html) but as an extention of FeatureCollection. interface SortedFeatureCollection extends FeatureCollection { SortBy[] getOrder(); SortedFeatureCollection subCollection( String fromId, String toId ); } I think this would be *way* easier to implemented then FeatureList - and would be more correct. The difficulty with FeatureList takes several forms: - By extending List<Feature> we are forced to make use of a new Abstract Collection implementation - bleck more chance for mistakes - By extending List<Feature> we are forced to not quite implement get( int ) and set( int, Feature ) - while the idea is good for random access, the set method would allow people to violate the sorting order - basically it is a bad idea The downside is this - we have never gotten around to admitting that a Feature should not be in a collection more than once. This is true in modeling terms (ie what a feature collection means). I believe most of our implementations treat their contents in this manner (using an internal TreeMap sorted by FID for example). Regardless we should consider dropping FeatureList as I think it would make Justin's work easier. Cheers, Jody ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
