Re: Undo/redo implementation & JMI compliance

Hi,

Brian Smith wrote:
>>> boolean isContainerIdentical(ModelElement me) {
>>>     return me.getContainer() == me.getContainer();
>>> }
>>>
>>> This code could very well return false since the JMI implementation 
>>> could create a new instance object each time me.getContainer() is 
>>> called. So, potentially you could have a some diagram elements that 
>>> reference the "same" model element, but referencing different 
>>> instance objects.
>>
>>
>> Could you please provide  pointers to spec that suggest such behaviour?
>> Such behavior is very surprising to programmer and it is very easy to
>> prevent this in implementation. If specification allows it, I think 
>> that it is an issue with specification that should be risen.
> 
> 
> I couldn't find anything in the spec that forbids such behavior, so I 
> assume it is allowed. In particular, the spec only talks about something 
> like me.getContainer().equals(me.getContainer()); This is a weaker 
> guarentee than me.getContainer() == me.getContainer(). I am not sure in 
> the end if the distinction matters so much. Basically, it means that JMI 
> clients should never use IdentityHashMap or equivalent when working with 
> JMI objects. If the JMI implementation makes some effort to return the 
> same Java instance objects each time, there won't be any much reason to 
> worry about them building up in memory due to strong referencing. But, 
> at the same time, if you are trying to implement some kind of "unlimited 
> undo" then it seems wasteful to keep all of those JMI objects in memory 
> for purposes of potentially, maybe, possibily using them later. In NSMDF 
>  it doesn't matter because everything is in-memory anyway. But with MDR, 
> it seems that the repository could "swap them to disk" so to speak.

I agree with Brian that this behavior is completely OK. As spec. says, 
identity of objects is exclusively determined by the value of MOF ID 
(not by the identity of representing Java objects).
However MDR is implemented the way that o1 == o2 <=> o1.equals(o2) 
(given that o1 and o2 are valid JMI objects).
Brian, MDR does not require users to not keep hard references on 
returned JMI objects to work efficiently as the objects that MDR returns 
are just a very lightweight wrappers that have weak references to real 
dataobjects - so the data get swapped to disk anyway and the thing that 
user references is only something that remembers MOF ID and is able to 
lookup the corresponding data object using this MOF ID.

Martin