Hi Avi,

[Note: I am not at all sure what "Roel's notifications" are in this context
so I can't really comment specifically towards them. I'll just assume that
they're some kind of callbacks unless being told differently].

> But Roel was using exactly this example as to why the 
> currently available notifications were problematic -
> they sometimes happen halfway through the process.
> Since his notifications will always fire only once 
> the atomic operation has completed, it should be much
> harder to thoroughly hose an image, right?

One can make it harder but if it's a callback it comes at a certain price.
The basic problem is that the calling processes have been written under the
assumption of not being interrupted and if you insert a callback all of the
calling processes need to be reviewed.

For example, when we compile a method, then we *first* add it to the method
dictionary and *then* log the change. So if you introduce a callback in
#addSelector:withMethod: you may interfere with the system's logging
mechanism quite thoroughly. In order to make this "more robust" one can move
the event notification only after the logging has happened, but now you're
going to miss certain events (those that are not invoked via compilation
such as ChangeList>>restoreDeletedMethod).

If you insert a "safe notification mechanism" (such as notifying an
intermediary object which later on notifies the interesting parties) then
you have the problem of finding out when exactly "it is safe" to do so.
Unless you have a theory about "the way the world works" (such as in
Morphic: we're running complete cycles so after a completed cycle it's okay
to do these kinds of things) you'd have to insert lots and lots of "extra
notifications" (e.g., "it's fine to do some other stuff now") in all of the
calling processes which seems practically quite unfeasable.

So there you are. If you use synchronous callbacks, you either have to risk
breaking the system by putting the callback right at the place where it
happens or you'll have to put it into places where you will miss some of it.

'nuff ranted. 

Cheers,
  - Andreas

PS. Issues like the above (and I'm not even talking about security which is
an entirely different and very interesting issue here; just think about
time-of-check vs. time-of-use if you have unknown synchronous callbacks
inbetween) were what ultimately led me to writing the stuff which is now in
Croquet and Tweak.