Justin Deoliveira wrote: > Here is my feedback: > > * getInfo() > Already done. It was ServiceInfo and ResourceInfo. Proposal page explains we are not talking about catalog here. > I dont know why my vote says +0... i remember having serious > reservations on this one. Perhaps it is because i disapeared over this > last week. > You did not vote; hence the +0. > * 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? > He has; it would involve introducing a super class (but would allow us to force the parameters to be exactly what we want). I asked him to avoid generics since: - it involved more moving parts - it is generics > I think the name of this class is pretty bad to. > Alternate suggestions: ComplexStore, ComplexDataStore, ... do you have anything? > * 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. > I don't have my heart set on FeatureStore extends ExtendsFeatureStore. > 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. > * ComplexFeatureReader/ComplexFeatureWriter > Generics are required if we want to "narrow" the parameters. I was aghast to see: addFeatures( ComplexFeatureReader ) > 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. > > 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 can you write up the generics example? It is what is needed for a -1...
I am afraid I am out of time to help with this, not associating ComplexDataStore with DataStore is another idea. Cheers, 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
