Thanks Gabriel - that is a great post. > 3)Introducing a type hierarchy with parametrized types for method parameters > may well worth a try, as it would cover all the use cases with no > overloading. > I have not tried writing this one up yet; should we try and see if the result is Okay? > For instance, those use cases are: > - client code that only knows how to deal with SimpleFeature (all of it so > far) gets only simple feature based datastores from the factory system. > Meaning everything keeps working just as it is with no breaks and no code > changes. > - client code that works with normal Features gets both complex and simple > capable datastores out of the factory system. All the current, simple feature > based datastores also work out of the box. >
That is a good summary; it seems to me the main stumbling block is the method parameter objects (like Query); can we add the information you need to Query with the understanding that it won't be that useful in the SimpleFeature/SimpleFeatureType case? Making this compormise would let us go with (2) "Introducing a type hierarchy with no types parametrization". Basically it is good to open up the kinds of content that can be returned; it is bad to open up the kinds of requests that can be made. This comes down to an earlier discussion between Justin and myself; I wanted to use FeatureCollection methods to open up the request space; and Justin wanted to spell out exactly what the request space is in an explicit Query object (adding methods to it as new WFS specifications come out), using FilterCapabilities to describe what abilities the datastore supports out of all the things Query can do ... He was right about about an explicit Query that time; I think it may be time to apply the same solution here. Jody ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
