Thanks for summing us this thread Andrea, excellent job. Thought I would throw in my two cents.
As someone who has implemented a feature collection before, I can say that time and effort is spent implementing methods that will rarely be called client code, only because they are part of the Collection contract. This added effort goes against where we would like to take the DataStore api, to be FeatureCollection based. If jody has not given you his "4 FeatureCollection" rant, then you should ask him :). On the other hand, its nice to be able to fall back on a well defined api instead of "rolling our own". So I can see the benefit to both approaches. As to Bryce's feedback, this is kind of agnostic to it. Andrea, what are your thoughts on relating a FeatureCollection to a "Collection" and a Feature through composition, instead of through inheritance? -Justin Andrea Aime wrote: > Jody Garnett ha scritto: >> Andrea Aime wrote: >>> 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. >> It could be Collection is not the right fit, Bryce and Justin were >> working through that and I am >> waiting to see what comes of it. What FeatureCollection represents >> however is spot on and >> much easier to both use and develop against. > > I will try to locate the thread. In the meantime, let me dump > on this mail what I thougth about during the evening. > The more I think about it, the more I'm convinced Collection is a bad > fit for data access. Before I start on details, think about it, why > Sun did provide you with Output/InputStream and JDBC ResultSet? > Aren't they conceptually just "collections" of bytes, and collections > of records? Why did Sun decided to have separate API and to throw > all those exceptions then? > > Taking this from a different angle, as a java developer used to > the java collection framework, I have certain expectations on anything > implementing the Collection interface (which is, by no means, something > explicitly stated in the Collections javadoc, just what experience > accustomed me to expect): > 1) calling size() is darn fast. All collections do really cache that > value, so it's like accessing a field. Nothing bad can happen. > 2) iterating over values of the collection is something that will > no to throw exceptions, unless I'm doing something like parallel > modifications > 3) if I call size() twice in a row I'll get the same result, if I scroll > twice against the collection I'll get the same results unless my > software did change the contents -> I own the contents > 4) Collections may be unmodifiable, but even in this case they allow > me to directly alter their contents, that is, you can't add or > remove, but they do not return clones of their contents, so if you > modify something, you do really modify it, next time you iterate > on the collection, you'll get the object as you modified it. > > The Collection API does not throw exceptions because it does not suppose > you're doing IO, does not provide listeners because it does not suppose > collection contents can change behind your back. > > FeatureCollection is all the opposite, it does streaming IO, it does not > have contents, but it's just a mediator to the real content owner (the > storage). > > We should not try to hide reality from users. The original gt2 > collections did not do that, because they were memory based, so they > were real collections. The Hibernate collectins are real collections > too, once you get an hold on them, they are memory based, persistence > is none of your business when dealing with them, you can get exceptions > only when playing with Session methods (which do throw exceptions, > either checked or unchecked depending on the hibernate version). > > So, my point is, FeatureCollection is not really "easy" to use, because > it provides the wrong message. It's easy to misuse instead. > Maybe we can have a FeatureCollection, but without making it implement > the Collection interface, without using real Iterator. We could have > similar methods, similar iterators, but with proper exceptions thrown, > with proper closing methods on iterators, and with a clear message that > you're no more playing with the collection framework rules and expectations. > Disk or network IO is a different kind of beast, ignoring it, or > setting the stage for the user to ignore it, it's just like saying > that we want to promote software that falls pray of each one of the > eight fallacies of distributed computing: > "http://today.java.net/jag/Fallacies.html";, also well explained > here, http://www.joelonsoftware.com/articles/fog0000000041.html > (third wrong idea, network transparency). > > 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 > > !DSPAM:1004,4596f120147654750375898! > -- Justin Deoliveira [EMAIL PROTECTED] The Open Planning Project http://topp.openplans.org ------------------------------------------------------------------------- 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
