Re: Undo/redo implementation & JMI compliance

Hi Constantine,

Holger could probably answer about use cases for undo/redo but I assume 
that most people are interested in undo/redo for graphical editors and 
similar tools.

>> 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 expect that editor that need undo/redo will mosly have
> document oriented "load/edit/save" model of work rather
> then repository  model "chekout/edit/commit". Possibly
> there are usecases when metadata is much less like the
> document, but I doubt that undo/redo will do any good
> for such case as undo/redo model had been developed
> for "load/edit/save" model of work and may work or not
> work for other models of work.

I agree, that is how the stuff I am working on does things: (1) load 
file into JMI extent, (2) manipulate model in extent, and (3) write file 
back out when I'm done. But, it seems that MDR is being built for use 
cases that require models so large that they can't possibly fit in 
memory all at once, but perhaps those types of uses have anything to do 
with undo/redo.

- Brian