Re: JMIUNDO SPI 0.2

Holger Krug wrote:
> I finished the handling of attribute change events. During this work I
> discovered a certain deficiency of JMI which makes tracking of
> attribute change events in the case of nested collection types
> impossible. I describe this deficiency at 
> http://www.rationalizer.com/jmiundo0.2/com/rationalizer/jmiundo/spi/RepositoryProxy.html#getCollectionEntry(java.util.Collection, java.io.Serializable)

My understanding is that all datatypes, including CollectionType 
instances, are immutable. In your example, if you wanted to change any 
part of the collection, you would have to do something like this:

// ... TestClass tc = ...;
Collection c = tc.getUntrackable().clone();
// ... change c as you wish
tc.setUntrackable(c);

Note that "untrackable" will have both "get" and "set" operations 
because the multiplicity of the attribute itself is [1..1], even though 
the value is actually a collection [0..*] of collections [0..*].

> The SPI allows further the tracking of setters of structure
> fields. Although not part of JMI (because structures do not have an
> identity and hence are not modifiable) setters of structure fields may
> be provided by the repository. They are important for interactive
> applications to allow straightforward GUI implementations. Hence the
> UndoManager can track them.

I think that this is not necessary. All instances of subtypes of 
Model::DataType are supposed to act as though they are completely 
immutable. I don't think there is anyway that a conforming 
implementation could provide setters. The reason is that, if "a" and "b" 
are both instances of some datatype, and a.equals(b) at any point during 
the execution of the program, a.equals(b) must hold for the entire 
execution of the program. Otherwise, you lose the immutability semantics.

Do any JMI implementations allow you to modify the StructureField values?

Thanks,
Brian