Hi Peter,

Peter Dinges wrote:
> Hi Juan,
>
> thanks for telling me about the optimizations in Model and ActiveModel; I 
> guess I should have looked more thoroughly at which classes reimplement parts 
> of the mechanisms. I will add a paragraph to the implementation notes.
>
>   
>> - MorphicEvents are really something really different... They are not
>> message sends, but [...] stateful objects that are sent around until
>> handled.
>>     
> OK, I see your point. They do, however, fulfill the criterion of "signaling an 
> asynchronous state change" (the user pressed a key, etc.). Don't you think 
> that they should at least get mentioned? 
>   

Yes, sure. I just say that it is not a direct replacement for 
#when:send:to: and #changed/#update. Those are indeed redundant, but 
MorphicEvent is not IMO.

>> - You forgot the AbstractEvent hierarchy. While this is not as general
>> as #when:send:to: and #changed/#update, it is closer to them than
>> MorphicEvents are. AbstractEvent is used to notify various Smalltalk
>> tools of system changes.
>>     
> Concerning the AbstractEvent hierarchy: I do not know why I had not found this 
> one, but you are of course right, it deserves some paragraphs in the text. 
> Furthemore, Torsten Bergmann noted that Pharo additionally includes the 
> Announcements framework. So two more event mechanisms to choose from. :-)
>   

Right.

> Thank you very much for your comments. The next draft will certainly benefit 
> from them. Also thank you for your work on Cuis.
>
> Cheers,
> Peter
>   

Good! You're welcome!

Cheers,
Juan Vuletich