The ususal reason - unexpected aliasing effects. I.e. it means that code can never depend on Features not changing underneath them. Consider for example some extension which creates an index on top of a FeatureCollection which is contained in a Layer, and caches this index for future use. If the user or some other tool changes the geometry of one of the Features in the Layer, the index is now invalid. This can lead to unexpected failures or incorrect results.
Since Features are so visible to the user, this doesn't seem to be a big problem. I suspect this is because there are very few plugins which actually cache information about Features. And non-mutable objects are a bit more cumbersome to work with, so I'm not really proposing that this be fixed now. One design to mitigate this is to allow FeatureCollections to fire events when Features change. This will probably be necessary in any case to support true updatable, transactional DB layers, I think. Sunburned Surveyor wrote: > Martin, > > Why would mutable Features be a bad idea? > > SS > > On 7/9/07, Martin Davis <[EMAIL PROTECTED]> wrote: > >> Stefan Steiniger wrote: >> >>> my 2 cents: >>> i think my first implementations also modified coordinates of layer >>> geometries directly. But in general, i always copy a geometry and modify >>> the coordinates with coord.x >>> >>> >> Good - that's the right way to do it. >> >>> Otherwise, what would be the way to do map generalisation (such as >>> applying a line smoothing algorithm that displaces vertices without >>> changing the number)??? I know, that by using the Douglas Peucker >>> algorithm a new Geometry object could be created afterwards, but here as >>> well online-modification may be worth? >>> Hence, for me Geoemtries are mutable. (But suggestions are welcome) >>> >>> >> For any operation on a Geometry, you can always create a new Geometry to >> represent the result of the operation. This Geometry can be stored back >> in the the Feature object the input came from. >> >> Note that this implies that Features are mutable. I'm not 100% sure >> this is a good idea either - but it's less bad than mutating Geometries. >> >> -- >> Martin Davis >> Senior Technical Architect >> Refractions Research, Inc. >> (250) 383-3022 >> >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by DB2 Express >> Download DB2 Express C - the FREE version of DB2 express and take >> control of your XML. No limits. Just data. Click to get it now. >> http://sourceforge.net/powerbar/db2/ >> _______________________________________________ >> Jump-pilot-devel mailing list >> Jump-pilot-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >> >> > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > 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 DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
