[self-interest] delegation versus design patterns

[Jecel Assumpcao Jr]

On Fri, 24 Nov 2000, Albertina Lourenci wrote:
> In Gúnther Kniesel's Ph.. thesis, page 165  he states:
> These are no problems of the deisgn patterns themselves, but of the
> underlying object model, which provides no suitable means to
> implement the patterns.

Which means your subject line is rather strange since he is trying to
show that delegation helps design patterns.

> He says to look at the book of the GOF
> page 309 where he states dynamic inheritance would be a desirable
> implementation for the state pattern. This was found in an earlier
> version of Self!

Self 4.1.2 does have dynamic inheritance. It is just that it doesn't
perform as well as static inheritance. I have proposed an
implementation trick to get good performance in the common case (using
multiple "map objects" for a single "clone family").

> The granularity of language support for design patterns is subject to debate.
> Some authors insist that every pattern needs its specific language support,
> others point out that this would be overwhelming and argue that the common
> needs of many different patterns should be identificied and
> supported by generic mechanisms.

  "Perfection is achieved, not when there is nothing left to add, but
   when there is nothing left to take away."
     Antoine de Saint-Exupéry (1900-1944)

I think most people interested in "the Power of Simplicity" would agree
with that one. Of course, using a single, powerful, mechanism for
everything can make it hard to express intentions. For example, using
"goto" instead of "if then else", "while", "for", "case", "loop" and so
on is not a good idea.

> I was afraid of Lisp because it is atyped. Besides the fact it
> doesn't feet my needs.

This is a common misconception. There are many kinds of types and just
because LISP is different from Pascal does not make it an untyped
language. The difference is where (and, as a consequence, when) the type
information is defined:

  Pascal
      - static types
      - each container (variable) is associated with a type at compile
         time

  LISP
      - dynamic types
      - each object (value) is associated with a type at run time

There are untyped languages (Forth, B, machine language) but they are
very different from dynamically typed ones (LISP, Smalltalk, Self,
APL).

> Then in 1996 I read a paper written by Ole Agesen and
> published at ECOOP'95 where I realized that only in appearance Self is
> not typed for the user. The types are all included in the compiler.
> Sorry I do not have the paper with me here.
> 
> So can you explain to me how this story works?

His work is a very interesting application that run on top of Self -
you seem to have the impression that it is part of the implementation
of the language but it isn't.

In Dave's talk at ECOOP'95 he defined two kinds of types:

   - abstract type = the set of objects which understand a given set of
                                messages. helps the programmer find
                                errors in the code

   - concrete type = the set of objects that have the same memory
                                 structure and method implementations.
                                 helps the compiler generate efficient
                                 machine language code

The Self programmer doesn't declare types, but the compilers create
their own notion of concrete types for objects (using "map" objects) in
order to save memory and enhance performance.

Ole's program can look at a group of Self objects and automatically
separate them into sets representing abstract types.

Most languages mix these two kinds of types together into a single idea
and cause a lot of confusion (see C++, for example). Combined with the
static/dynamic kinds of types, we can see the following in Java:

  static abstract type = the interface of a variable
  static concrete type = the class of a variable
  dynamic concrete type = the class of an object stored in the variable
                                        (must be a subclass of the
                                        concrete abstract type or a
                                        class which implements the
                                        static abstract type for that
                                        variable)

> Then I fell in love with Self  and abandoned programming in Beta.

Perhaps you should reconsider this since Günther is wrong about his
language being the first static one to implement delegation. It seems
to me that Beta's "part-object inheritance" is exactly that.

> [page 39, page 40-48]
> Honestly this kind of analysis I cannot even read.
> What's wrong here? I do not know because I am able
> to follow detailed papers like those written by
> Luca Cardelli or the above written by Ole Agesen.

Maybe you have not understood all these papers as well as you think you
have....

> In page 50 he concludes stating that the most promising
> approach to unanticipated behaviour evolution is the
> integration of delegation into statically typed class-based
> models.
> 
> Can someone explain to me in a way that  enables
> a right-sided thinker to understand this?

He just said that prototype based language can easily implement the
various design patterns directly (with object modification, which he
thinks is bad, and with delegation, which he thinks is good), while the
class based ones have to use complicated simulations of delegation
which make everything much harder to understand. And if you add static
types things get even worse since then the simulation doesn't even work
anymore!

So his conclusion is that we should fix the statically typed class
based languages by adding delegation to them and getting rid of the
simulation. My conclusion is that I will keep using a prototype based
language :-)

-- Jecel