Jody Garnett wrote: > 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. Yeah, but you took the catalog interfaces and put them on the datastore api. Just because they are not in the catalog package does not mean they dont suck anymore. All those attributes mean nothing in the common case. What does publisher mean to shapefile? They should go in a subclass. Anyways, i will bring this up at next irc. Those interfaces as is are unacceptable in my opinion.
> You did not vote; hence the +0. Because I gave negative feedback expecting the proposal to be reworked. Apparently i dont understand the process. It is the responsibility of the person who gives feedback to update the proposal? That does not work for me. >> * 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. And i dont have my heart set on a whole new set of interfaces. Generics can be effective if used properly. I think we have a chance to use them properly here. And besides, a bunch of our code already uses generics (like all of the modules martin maintains). So what is the hesitation here? > 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 will try, i dont know when i can get to it. Hopefully this does not mean that the proposal gets accepted just because i did not write up my feedback. > > I am afraid I am out of time to help with this, not associating > ComplexDataStore with DataStore is another idea. > > Cheers, > Jody > > !DSPAM:4007,47aa1cd8149821849620573! > -- Justin Deoliveira The Open Planning Project [EMAIL PROTECTED] ------------------------------------------------------------------------- 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
