Good discussion Andrea, I am sorry I cannot give this my full attention. > 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. In talking to Justin it sounded like they came up with two conclusions: - "Collection" was not a good fit for FeatureCollection (not sure of the details on this one) - "Feature" was not a good fit for FeatureCollection (gah? It is what the OGC reference model says?)
I am going to try and locate the thread as well > 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? I do not believe they were trying for abstraction in the same manner as we are. I found a Jakarta Commons class here that is a better fit for FeatureCollection / FeatureList then anything in the pure Java grouping: - http://jakarta.apache.org/commons/collections/userguide.html#Ordered%20Maps > 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): The Javadocs do provide some guidance on what you can expect from the API, let's see how your assumptions hold up. > 1) calling size() is darn fast. All collections do really cache that > value, so it's like accessing a field. Nothing bad can happen. I was thinking LinkedList says otherwise. > 2) iterating over values of the collection is something that will > no to throw exceptions, unless I'm doing something like parallel > modifications This is the crux of the matter is it not? ConcurrentModificationException is not document as an explicit restriction (it is just something implementations can restrict if they want), as such it only shows up as a RuntimeException and is not part of the signature. This is something only produced by a "fail fast iterator".... and only as a result of the provided implementations not being thread safe. > 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 I see the conflict in meaning, a Collections.synchronizedMap( map ) shared between threads would not make this assumption. Similarly you should not make it on a FeatureCollection backed onto a database. > 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. This tends to very from implementation to implementation, you can see JDom for example of collections that hold their contents in check (or not) as needed. Our implementations do actually allow modification, they will perform a write as needed etc. FeatureReader does return a copy, but the iterator() method is based on FeatureWriter and should write() any modifications back as needed. Your point is noted, I would love to wrap the returned Feature and provide a isDirty() flag for a cheaper check then duplication. > 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. This was a scope check on their part: - http://java.sun.com/j2se/1.4.2/docs/guide/collections/designfaq.html#27 You can find some examples in swing with collection that throw events as needed. > 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). This should be viewed as similar to a HashSet delegating content storage to an internal HashMap. > 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). But yet hibernate does have close( Iterator ) - http://www.hibernate.org/hib_docs/v3/api/org/hibernate/Hibernate.html#close(java.util.Iterator) It is worth looking over hibernate Query and the iterator(), scroll() and list(). Also note that hibernate iterator() method results in something that can throw runtime exceptions (according to their docs): > Unfortunately java.util.Iterator does not declare any exceptions, so > any SQL or Hibernate exceptions that occur are wrapped in a > LazyInitializationException (a subclass of RuntimeException). (from http://www.hibernate.org/hib_docs/reference/en/html/manipulatingdata.html) > 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). So that is the conflict, back when "Bring Back FeatureCollection" occurred I could not make the case for keeping FeatureResults around. The request was made in terms of ease of use, your point that ease of use makes things that are hard look too easy is also valid. I am content with the current approach, but I cannot honestly recommend it to you right now as implementations are not here to back me up. I would really like your help moving the library away from FeatureReader/FeatureWriter, but it is hard when it seems success is needed to help convince you (sigh). Jody PS> I would like to look at that hibernate Query API a bit more with respect to your feedback on the DataAccess API. ------------------------------------------------------------------------- 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
