While I like the idea of removing the duplication I think the real problem is in all the FeatureCollection implemetations that lie around and do something different. I am fine with FeatureCollection duplicating FeatureSource api as long as it makes it more convenient for the user. But currently FeatureCollection is meant for direct data access so it does indeed overlap.
Can we somehow merge this with the proposal to unify FeatureCollection into a single implementation wrapped around a FeatureSource? Or is that a separate beast? On 10-05-25 7:05 AM, Andrea Aime wrote: > Jody Garnett ha scritto: >> As andrea indicated in his last email there is certain amount of hate for >> the duplication between FeatureSource / FeatureCollection :-) >> I would like to start stripping abilities out of FeatureCollection in a >> careful controlled manner. >> >> Today I have my first candidate for removal: >> - addListener(CollectionListener listener) throws NullPointerException >> - removeListener(CollectionListener listener) throws NullPointerException >> >> Reasons: >> - AbstractFeatureCollection maintains a list of listeners ... but never >> fires events to them >> - indeed I can only find one implementation that looks like it works ... >> ContentFeatureCollection >> >> The idea of issuing events here encourages users to keep a feature >> collection around and modify it; a case where we want to encourage >> FeatureSource. > > (this time answering the right mail) > Sounds like an improvement to me. +1 > > Cheers > Andrea > -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------------------------------------------------------ _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
