Thanks for the reply: if understand everyone correctly the best course of action is ... - deprecate FeatureList in 2.4.x - remove it from 2.5.x (ie trunk) even if it is just so Justin has less to cope with
Long term (ie for GeoAPI ) we should seriously consider just removing it, and if not look into an idea like SortedFeatureCollection (ie List<Feature> is killing us). Jody > Jody Garnett wrote: >> 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 ); >> } > > Please no!!! Not another interface... I would be fine with another > interface but not before the problem of feature collection being both > a feature and a collection is addressed. >> >> >> 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. > On the contrary the mass amount of feature collection interfaces: > > FeatureCollection > ResourceCollection > FeatureList > ResourceList > > has made my life hell during the feature model work. >> 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 >> >> !DSPAM:4007,469cfa5543341439371379! >> > > ------------------------------------------------------------------------- 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
