Jody Garnett ha scritto: > Andrea Aime wrote: >>> Perfect! This is exactly the kind of thing I was hoping for as we set >>> up FeatureList. >>> >>> FeatureCollection.sort( SortBy ).iterator() should give you a "sorted >>> writer". The iterator should let you work over top of a sorted result >>> set :-) >> I have a preference for working against FeatureReader and FeatureWriter >> because they're simpler and more predictable imho, so I would really >> like a public DataStore call that sounds like: > And I am trying to kill these things as a mistake :-( That is they are > too low level, useful for implementing, but not so much to work against > (they throw too many exceptions and do not follow the collections api).
I have the exactly opposite impression? FeatureCollection is confusing and breaks normal way of doing things, FeatureReader and Writer and simple and straightforward. Having to throw runtime exceptions because you had an internal probelm in an iterator is what I call error prone and hard to deal with. You expect it to be a normal collection, then it starts throwing exception here and there. >> FeatureWriter getFeatureWriter(String typeName, Filter filter, >> SortBy[], Transaction transaction) > You are welcome to add that to your DataStore, I ask that you out the > ability as the backing of FeatureList if you don't mind. I do... I'm not interested in FeatureCollection at the moment, find it confusing and out of place, can't we have a wrapping mechanism so that your collections call that method when they need a sorter writer? >> In the end, I believe we need the same thing, since to implement >> FeatureList you need the datastore to provide you some way to sort >> writers, no? > You are correct we need something like this, but I have provided no help > as part of AbstractDataStore for implementors at this time. Well, I'd really like to have that one as an addition to the DataStore interface, although it breaks compatibility. Maybe as a subinterface? >> Oh, btw, you said FeatureCollection.sort( SortBy ).iterator() gives me >> a sorted writer? You do mean that every time I do call next() a call >> to write() against the wrapped writer is implied? > You asked about API, yes this is the way to get a sorted iterator that > can do read or write. The code copies > the feature, and when next is called it looks if anything was modified, > and if so does a write. Iterators have been provided around both > FeatureReader and FeatureWriter, so if you can *know* your user is not > doing any writing you > can use the faster one with no checks. ie DataStore.getView( Filter > ).sort( SortBy ).iterator() is readonly .... I see. I'll keep on using my loved feature readers :-p No suprises, no hidden costs... >> Moreover, the (nicer imho) FeatureIterator does not have a remove() >> call, we should add it then? > FeatureIterator literally is just a hack to get around our lack of Java > 5, it should extend Iterator<Feature>, so if you want to make one that > extends ListIterator<Feature> (I think that is where remove comes from?) > then that would also be cool. I keep on not getting why the hack misses remove thought. Cheers Andrea ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
