Andrea Aime wrote:
> Jody Garnett ha scritto:
>> Andrea we *do* ask that an Iterator get's closed when it falls off
>> the end, but this does not
>> protect us in the event of IO Error.
>>
>> It could be we have made a bad tradeoff, and should ask each iterator
>> implementor to clean up everything as their throw an IOError (it
>> force implementors to take on the "finally" pain once so all the
>> client code does not have to).
>>
>> Defined as is the implementors were "easy" to write, getting rid of
>> close( Iterator ) would swing the library more in favour of the user
>> community would be a large QA task, added to the list of
>> FilterVisitor, FeatureBuilder and FeatureTypeBuilder QA tasks already
>> slowing us down.
>
> I'd definitely like it to be me more user friendly. But in fact,
> I think FeatureIterator is ok, it has a close method you can call if you
> drop off the iteration earlier and does not break the iteration idiom:
>
> for(FeatureIterator it = coll.features(); it.hasNext(); ) {
> Feature f = it.next();
> if(myFilter.evaluate(f)) {
> // some code
> it.close();
> break;
> }
> }
>
> and... oh, you're right, in case of exception the iterator is not closed.
>
> Having FeatureCollection extending collection is worse too, since
> a simple Iterator does not have a close method. And, it gets worse
> too. Think someone calling
> Collections.min(featureCollection, comparator),
> or someone doing "new ArrayList(featureCollection)": those operations
> will open up an interator internally, and you don't have any control
> against it (some generic algorithm may indeed decide to drop iteration
> before end and you can't do anything about it!!!).
Yep - this was part of the discussion in the "bring back feature
collection debate" with James. We have FeatureCollection.purge() for
these cases ... and follow what I was told was the hibernate idiom with
FeatureCollection.close( iterator ) for the other cases.
> So I guess I'd like to ask that:
> * every feature iterator returned is able to close itself once
> iteration ends, and before every exception is thrown (its state should
> be badly compromised and beyond repair, no?);
> * avoid having FeatureCollection implement
> Collection... if we cannot trust a generic collection based algorithm
> to work against our collection, we should not allow it to, no?
I think having access to the collection based stuff was part of the
point :-( I am more concerned about making the API easy for people to
get started up with, (as opposed to reusing generic collection based
algorithms). But I gotta realize that the first thing most normal
programmers will do is stuff things into an ArrayList, by having out
interfaces implement Collection out of the box we can encourage the
production of software with a hope of scaling.
Have a look at "purge" Andrea and let me know what you think, it should
let us use collection based algorithms. I am interested in seeing how
Justin's and Bryce's conversation works out; it could be we have a good
reason not to implement collection.
Jody
-------------------------------------------------------------------------
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
