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/org >/geotools/data/DataAccess.java > http://svn.geotools.org/geotools/trunk/spike/jdeolive/api/src/main/java/org >/geotools/data/DataStore.java > http://svn.geotools.org/geotools/trunk/spike/jdeolive/api/src/main/java/org >/geotools/data/FeatureSource.java > http://svn.geotools.org/geotools/trunk/spike/jdeolive/api/src/main/java/org >/geotools/data/FeatureReader.java > http://svn.geotools.org/geotools/trunk/spike/jdeolive/api/src/main/java/org >/geotools/data/FeatureCollection.java > > And the example: > > http://svn.geotools.org/geotools/trunk/spike/jdeolive/example/src/main/java >/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
