The Weekly Juan #2: Morphic 3.0

Hi Folks.

The Weekly Juan #2 is out at www.jvuletich.org . Today I talk a bit
about my New Morphic project.

Hope you like it. Any comment is welcome, especially discussion about
the ideas and the design.

Thanks,
Juan Vuletich

At 00:27 22.10.2006, Juan Vuletich 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).

"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.

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 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.

This is too long already, so I just end with
My best wishes for you applaudable efforts
--Trygve


--

Trygve Reenskaug      mailto: [hidden email]
Morgedalsvn. 5A       http://heim.ifi.uio.no/~trygver
N-0378 Oslo           Tel: (+47) 22 49 57 27
Norway

Hi Trygve,

Trygve Reenskaug wrote: 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

At 00:27 22.10.2006, Juan Vuletich wrote:
> Hi Folks.
>
> The Weekly Juan #2 is out at www.jvuletich.org . Today I talk a bit  
> about my New Morphic project.
>
> Hope you like it. Any comment is welcome, especially discussion  
> about the ideas and the design.

I like it, indeed :) Factoring out the non-intrinsic aspects from the  
base object is a good idea. This, and in particular your geometry  
discussion reminds me a lot of Tweak aspects - which work by delegation:

        http://tweak.impara.de/TECHNOLOGY/Documentation/PlayerAspects/#geometry

Also, for a canvas with anti-aliased rendering, have a look a Rome,  
which is an abstraction layer with Balloon2D and Cairo backends:

        http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-August/ 
107706.html

- Bert -

Thanks Bert.

Currently I'm using Balloon2D. But I could switch to Rome sometime, to
also have Cairo.

Cheers,
Juan Vuletich

Bert Freudenberg wrote: