Hi Trygve,

Trygve Reenskaug wrote:
>
> Hi Juan,
> Yes, I do like it. Reducing the responsibilities of the base Morph 
> class can only lead to a much simpler system. The danger is that the 
> complexity will be reintroduced in the subclasses. As you say, it was 
> the "enhancements" that made the current Morphic so intractable. Yet, 
> the substance of every enhancement was needed by somebody at some 
> time. Many of the enhancements are now widely used in many contexts.
>
> I believe that the difficulties with Morphic were caused by the lack 
> of a document clearly laying out how to do extensions and what to 
> avoid. It could be in the form of an architecture document or possibly 
> a pattern language. (A pattern language could be preferable because it 
> is concise and extensible).
I don't have a complete answer for this. All I know is that users of the 
framework should try to refrain from modifying framework classes. You 
usually don't add to Object lots of methods that only make sense in your 
"business model". We should keep in mind that there is a potential 
problem, and learn more about it in the process.
> "The Morph hierarchy should not be a hierarchy of shapes." I take it 
> you will be using delegation rather than subclassing for different 
> shapes. This should take care of a great many problems with enhancements.
Maybe delegation, maybe Traits, maybe just a custom #drawOn:. Anyway, it 
is not something that should be enforced by the framework. It's a 
decision for the programmer of each morph.
> It will be very interesting to see how you intend to handle input. (I 
> have spent many hours trying to understand why a certain morph got 
> balloon help while another didn't, and I still don't know the answer)
I haven't thought much about this yet. May be it will not be very 
different from current Morphic.
> I sometimes see an unfortunate trend to hide the "dirty details" of a 
> new paradigm implementation (e.g., in a superclass or behind an 
> unspecified interface). I hope you plan to avoid this trap. The beauty 
> of Smalltalk is that everything is there to be studied and even 
> modified by anybody. Hiding stuff behind a smoke screen perverts this 
> principle. Do it right, do it simple, do it transparent. Then all 
> kinds of wonderful edifices can be built on top of it.
I'm not sure if I understand what you're saying. But I'm a big fan of 
simple designs.
> This is too long already, so I just end with
> My best wishes for you applaudable efforts
> --Trygve
Thanks!
Juan Vuletich