To tell you the truth, this is the way I thought it actually
worked--since I'd never actually changed attributes on a component
programmatically before. After looking at this, I was quite
distraught and thought "boy this is going to eat up memory." This is
definitely something that needs to be done in my opinion.
It also now makes me want to avoid the Options module and a few
others that have to actually copy the entire array when playing with
attributes.
David
The problem is that objects carry attributes and can be shared. If you
change an attribute on a shared object, you change it everywhere the object
is used. The only way to avoid this often disasterous side effect is to
copy the object and then put the new attribute on the copy. However,
unlike other types of objects, Arrays can be *very* costly to copy, so we
try to avoid it by hiding the interface to do so and, in doing so, confuse
the crap out of everybody.
IMHO, the right thing to do here is to create a new object, ArrayData, that
actually carries data, and let Array reference an ArrayData object rather
than hold the data itself. By doing so we separate the header, which
carries the semantics of how the data is used (eg. "dep" and "ref"
attributes) from the data itself. We then preclude the attachment of
attributes on ArrayData objects. Now, if we want to change the semantics
of an Array object, we can copy it cheaply, creating a new Array object
that references the same ArrayData object.
Greg
--
.............................................................................
David L. Thompson Visualization and Imagery Solutions, Inc.
mailto:[EMAIL PROTECTED] 5515 Skyway Drive, Missoula, MT 59804
Phone : (406)257-8530
