Sunburned Surveyor wrote: > > So do I have to create a copy of each Feature object in the > FeatureCollection using the new schema and over write the existing Yup > On a related note, would it be handy to have a Feature implementation > that changed its internal state when its FeatureSchema reference was > changed? > Or just make a helper class to perform all the changes for you.
JUMP tried to make Feature objects immutable, since we thought it was more useful to all them to be shared safely than to allow them to be mutated. I would strongly recommend continuing with this philosophy. Mutating features introduces potential for all sorts of nasty aliasing bugs. In general I think mutating objects made more sense when memory was scarce and memory allocation was expensive. Neither is true in modern machines and modern Java. My 2c M > Maybe I am missing something obvious. > > Thanks for any suggestions. > > The Sunburned Surveyor > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > -- Martin Davis Senior Technical Architect Refractions Research, Inc. (250) 383-3022 ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
