Justin Deoliveira ha scritto: > 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?
Hem... the OGC model say that a FeatureCollection is a Feature indeed, then I ask you, what is the FeatureCollection identity? Surprise, it does not have one. This is because we are mixing two different concepts: * collection as part of an object model. This is stretched, but it may be that we can somehow build an identity for it, thought I'm not very convinced. * collection as a query result. This has no identity at all, it's just a transient thing that allows me to access the results. As for attributes, what are the collection ones? Hmm.. we could say it has a size, but again, this seems to me like forcing a cube into a round hole. Does FeatureCollection hold a Feature? It holds a collection of them for sure. Does a FeatureCollection hold a collection? Hmmm... FeatureCollection as it is now is just a mediator, not a data holder.... Yes, it could give you back an in memory based standard collection. My point is, if you want the easiness of standard collections, you have to be prepared to give up scalability. FeatureCollectin as it is tries to be scalable, but if you really want to use it, it's just as complex as a real I/O API, because you have to deal with exception, and with the aggravation you don't know what exceptions implementation can throw at you. I prefer an API that tells me what can go wrong, otherwise I'm back into VB6 land where I have to hope exceptions get thrown during development so that I can add handlers for them (hint, in VB6 there's no way to know what throws an error, what codes can be thrown, and what's their meaning...) 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
