Justin Deoliveira wrote: >> There were two hesitations: >> - when Gabriel started generics were not needed; where he ended up it >> looks like they may be required > I dont understand what this means. It means he was only focused on: FeatureAccess.getSchema(): FeatureType DataStore.getSchema(): SimpleFeatureType
When he started in on parameters; he defined something that could not be built: ComplexFeatureSource.getFeatures( ComplexQuery ) FeatureSource.getFeatures( Query ) Having a subclass relationship on a method parameter cannot be done; unless you use generics; and introduce a common superclass. >> - the other one is his deadline; I am not confident that we can >> explain a set of classes that use generics well enough to get the >> proposal approved. > I disagree. I think supplementing the classes we have with generics > will be more clear than introducing 5 new classes, and 5 new > inhieretence relationships. 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,...> > Sorry, but a deadline is no excuse to crap all over the api. I would > rather if people have these sorts of deadlines they hack outside of > public api. And for deadlines I assume you mean gabriel and the wfs > datastore for the fgdc project. One of the main reasons topp applied > for funding was to get complex features on trunk the *right* way. We > want to deliver something soon but not if it means screwing up our > data access api more then it already is. Fair enough; I have not had time to work on this so I have been volunteering and checking Gabriels work as it happens; if you need to be involved to do this the right way then leap in. 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
