[EMAIL PROTECTED] wrote on 06/07/2006 12:41:52 AM:
> Which needs are we trying to solve? Need #1: Type checking on collections. Need #2: Synchronizing "owning" objects with a backing set. > If the only thing we need is a > listener to be used by our > implementation only, I would prefers to avoid the Apache common > collections for the following reasons: Umm, we're already dependant on commons-collections via the arcsde plugin, which uses commons-pool. commons-events (the dead code I'd like to add) is more like 18k. There's no direct usage of commons-collections in GT, but we're dependant all the same. > - The decorator pattern is a nice design, very useful when the > amount of classes is not > very large. For a large amount of collection (as I would expect > in geometries), it is > going to put a significant burden on the garbage collector and > consume more memory. > In the particular case of HashMap and HashSet from J2SE, there > is only one method to > override in order to get our listener behavior. See comment on GEOT-865. This is not our largest garbage collector/memory problem. Retooling the geometry implementation for memory efficiency is going to require much more than attention to just the collections interface. In the mean time, using the decorator pattern means we don't have to re-implement type checking and synchronization in every Collections implementation we write. Subclassing AbstractCollection does require that. It also requires making one implementation for each combination of functionality we want to have avalable. (e.g., two functions means four combinations. These are implemented for Collection, List, Map, and Set: 16 classes with largely the same code. Now throw in "automatic transform"...) In the end we may have to copy our code to every class, but we're not yet at the point where we can evaluate whether the gain in efficiency is worth the duplication of code/maintenanence headaches. Implementing 19107/GeoAPI is a guaranteed ObjectFest, and not a lot of them are Collections. Bryce _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
