Go ahead and merge; there are a couple of cases where we have made "version 2" of a class as a copy so as not to disturb currently running classes. The most obvious example is AbstractDataStore vs ContentDataStore.
Jody On 15/08/2010, at 9:14 AM, Gabriel Roldan wrote: > Hi, > > there are two versions of FeatureReaderIterator: > org.geotools.feature.FeatureReaderIterator and > org.geotools.data.store.FeatureReaderIterator > > Both do basically the same. The former is public and the later package > private. > DataFeatureCollection does a couple instanceof checks on the later, which > makes it > hard to subclass it as we can't rely on > org.geotools.data.store.FeatureReaderIterator from another package. > > Yet, org.geotools.data.store.FeatureReaderIterator does things a little > better than it's public counterpart because it auto-closes upon an exception > in hasNext() or next(). > > I can live overriding the necessary methods in DataFeatureCollection to > overcome the situation, but think it would be better if we leave only the > public version and make it as smart as the package visible one? > > Comments welcome. > > Gabriel > ------------------------------------------------------------------------------ > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > Geotools-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel
------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
