> * FeatureAccess > > I dont know how I feel about a new interface. I think we may want to > consider a different solution with generics. Not that I love generics > but in this case they may better apply. I assume gabriel has thought > about this route?
Indeed that was my first intention but got strong advice about avoiding generics in our API. Also an approach introducing generics will throw a lot of warnings in client code I guess. > > I think the name of this class is pretty bad to. could be, choosing good names is hard when they're already taken. Tackling the naming problem altogether, I agree having "Complex" as a prefix is odd, it'd be much better to have FeatureReader and SimpleFeatureReader etc, but that's seemed to be not an option thinking of users in last irc meeting. > > * FeatureStore > > Having FeatureStore extend ComplexFeatureStore seems odd to me. I know > that this mirrors the feature model but... In the least we *need* to > change the name of this to something without the word "Complex" in it. No problem in getting rid of the "Complex" prefix, it bugs me too. Ideas? > > But again... the new interface bugs me, and is invasive. From what i can > tell the main motivation is to be able to override methods which take a > feature reader with methods which take a ComplexFeatureReader. I am not > sure this is necessary, see next point. hmmm.. remember the main motivation is to work with Feature. The same way you can deal with SimpleFeature by its more generic Feature interface. not sure what you mean by being invasive though, since its a pull up of FeatureStore for the more generic case... > > * ComplexFeatureReader/ComplexFeatureWriter > > Again, not to beat a dead horse... but i think these super interfaces > are unnecessary and generics might be cleaner. I would even rather just > have next() return an object and have client code cast, rather then > break out a new interface. Let's see what others say, I for one would be glad of using generics, be sure of that. Gabriel > > So to sum up, this proposal needs to consider the alternative way of > doing this which is cleaner. Adding a bunch of super classes which are > poorly named gets a -1 in my book. Perhaps its impossible to do with > generics... but i think its worth consideration. > > -Justin > > Gabriel Roldán wrote: > > Hi all, > > > > the proposal to extend the geotools data access interfaces to allow > > working with GeoAPI Feature and FeatureType as a superset of the current > > API based on SimpleFeature and SimpleFeatureType is ready for your > > evaluation. > > > > The URL is > > <http://docs.codehaus.org/display/GEOTOOLS/FeatureAccess+super+class+for+ > >DataStore> > > > > And feel free to raise any concern as comments in the jira tracker for it > > at <http://jira.codehaus.org/browse/GEOT-1701> > > > > Best regards, > > > > 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 ------------------------------------------------------------------------- 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
