On Thursday 07 February 2008 01:15:52 am Justin Deoliveira wrote:
> > When I introduce generics to this picture I end up with more classes? We
> > best get specific...
> > - CommonSuperClassThing<X,...>
> > - ComplexDataStore extends CommonSuperClassThing<Feature,...>
> > - DataStore extends CommonSuperClassThing<SimpleFeature,...>
>
> Why do we have to add new classes? The only reason I would see is for
> convenience. I mean we just template datastore and the rest falls into
> place. I think the only classes we would have to create the superclass
> structure for would be DataStoreFactory.
>
> ComplexDataStoreFactorySpi {
> DataStore<Feature> createDataStore(..);
> }
>
> DataStoreFactorySpi extends ComplexDataStoreFactory {
> DataStore<SimpleFeature> createDataStore(..)
> }
>
> I admit maybe i am missing something fundamental, i have never been
> great at generics.
see my last post. Problem with this is generics will be erased at runtime.
Also we'll need to add methods to DataStore anyways like for working with
Name instead of String.
In the end its all about compromise.
1) Introducing generics and the required additions implies an alternative
method to really know if a DataStore produces Features or only SimpleFeatures
and brings a lot of warning to implementors upgrading to 2.5, that we being a
library may want to consider.
Also it makes the api open ended which really is not. i.e. it should be
DataStore<? extends FeatureType, ? extends Feature> in order to work.
2)Introducing a type hierarchy with no types parametrization makes things
explicit and closed ended , covers all the use cases, but imposes method
overloading in the current DataStore implementations for the methods that
receive FeatureCollection and FeatureReader.
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.
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.
Gabriel
-------------------------------------------------------------------------
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
