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
