Hi all, as code seems to work better for all than words, I've added a spike with samples for the third approach (should call it the first as it was the first one before being asked to introduce generics to overcome the limitations of this one)
Call this approach "nogenerics". It digs on adding a type hierarchy (mostly an interface pull up) for DataStore, FeatureSource/Store/Locking without using generics. So it relies on return type narrowing to return the special purpose FeatureReader, SimpleFeatureType, SimpleFeature and (simple)FeatureCollection. The drawback is DataStore and FeatureStore implementations get two new methods each, which are overloaded versions of the originals: DataStore: public void createSchema(SimpleFeatureType featureType) public void createSchema(FeatureType featureType) public void updateSchema(String typeName, SimpleFeatureType featureType) public void updateSchema(String typeName, FeatureType featureType) FeatureStore: public Set<FeatureId> addFeatures(FeatureCollection collection) public Set<FeatureId> addFeatures(SimpleFeatureCollection collection) public void setFeatures(FeatureReader reader) public void setFeatures(Reader reader) --------- So to sume up, we have three approaches, spikes and sample code: - Generics * code: http://svn.geotools.org/geotools/trunk/spike/jdeolive/api * example: http://svn.geotools.org/geotools/trunk/spike/jdeolive/example - Generics + Hierarchy * code: http://svn.geotools.org/geotools/trunk/spike/gabriel/api-hierarchy * example: package org.geotools.data.sample - Nogenerics * code: http://svn.geotools.org/geotools/trunk/spike/gabriel/api-nogenerics * example: package org.geotools.data.sample Please try to make your head around what you prefer as we would need a final by this monday's IRC meeting. Regards, Gabriel On Friday 08 February 2008 07:52:27 pm Gabriel Roldán wrote: > Hi all, > > for your consideration: > > The other approach is spiked at > <http://svn.geotools.org/geotools/trunk/spike/gabriel/api> > > both jdeolive's spike and mine introduce generics in the data access layer > to cope with parametrization of arguments, since return types > (featurereader et al) could be easily handled through plain return type > narrowing. > > Example fake implementations are at the sample package: > <http://svn.geotools.org/geotools/trunk/spike/gabriel/api/src/main/java/org >/geotools/data/sample/> > > Call jdeolive's spike "full parametrization" and groldan's spike "full > narrowing", differences/tradeoffs are: > > - full parametrization: > 1) cleaner abstract api > 2) does not incur in naming conflicts (no need to find good names beyond > the ones already in use and a superclass for DataStore) > 3) introduces only one more interface, a pull up of DataStore. This allows > for the separation of generic Feature capable datastores and > SimpleFeature-only capable ones. > 4) will break some existing client code when upgrading to geotools 2.5 due > to the runtime erasing of generics. Yet, its easily fixable with a regular > expression search and replace. > > - full narrowing > 1) cleaner concrete api for the DataStore case (ie, SimpleFeature) > 2) Incurs in naming hell since the good ones are already taken > 3) introduces a full layer of abstraction over DataStore, > FeatureSource/Store/Locking, FeatureReader/Writer, FeatureCollection > 4) Breaks less/no existing code. Only requires the addition of Name vs. > String (ie. DataStore.getNames():List<Name> vs > DataStore.getTypeNames():String[]) > > Personal opinion: I prefer the "full parametrization" one. > > Gabriel > > On Thursday 07 February 2008 10:19:05 pm Justin Deoliveira wrote: > > Hi all, > > > > As per the data access irc breakout i have created a spike which employs > > the changes. The spike is available at: > > > > http://svn.geotools.org/geotools/trunk/spike/jdeolive > > > > Its a maven project so you can build it and load it into your ide if you > > wish. However you need to have a geotools trunk already built in your > > local repo. And if you do built it you want to clear out the api module > > to get yoru local repo back to workign order. > > > > Here are the relevant links for those who just want to browse: > > > > http://svn.geotools.org/geotools/trunk/spike/jdeolive/api/src/main/java/o > >rg /geotools/data/DataAccess.java > > http://svn.geotools.org/geotools/trunk/spike/jdeolive/api/src/main/java/o > >rg /geotools/data/DataStore.java > > http://svn.geotools.org/geotools/trunk/spike/jdeolive/api/src/main/java/o > >rg /geotools/data/FeatureSource.java > > http://svn.geotools.org/geotools/trunk/spike/jdeolive/api/src/main/java/o > >rg /geotools/data/FeatureReader.java > > http://svn.geotools.org/geotools/trunk/spike/jdeolive/api/src/main/java/o > >rg /geotools/data/FeatureCollection.java > > > > And the example: > > > > http://svn.geotools.org/geotools/trunk/spike/jdeolive/example/src/main/ja > >va /Example.java > > > > Doing this has been a useful exercise. I am not even more convinced that > > this is the way to go for the following reasons: > > > > * All the code changes are mechanical and users have a choice to: > > > > 1) parameterize FeatureSource/FeatureReader/FeatureCollection > > 2) cast when getting features out of an iterator > > > > * The update path to Feature (complex) seems quite clean. No changing > > classes or references > > > > Anywho, if people want to see more examples just ask or feel free to add > > them to the spike as you please. > > > > -Justin > > ------------------------------------------------------------------------- > 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 > > !DSPAM:4045,47aca505207931096210785! ------------------------------------------------------------------------- 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
