delegation versus design patterns
Albertina Lourenci
lourenci at lsi.usp.br
Mon Nov 27 20:32:20 UTC 2000
Jecel Assumpcao Jr wrote:
> 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.
>
I would rather say it is strange the way you are quoting things!
Günther stated on page 166
However the granularity of language support for design patterns is subject
to debate. Whereas some authors insist that every pattern needs its
specific language support, other point out that this would be overwhelming
and argue that the common needs of many different patterns
should be identified and supported by generic mechanisms.
Günther thinks that delegation is such a generic mechanism.
However he shows in chapter 3, pages 40-48 that simulation of
delegation in traditional typed-languages leads to a dead end!
So he concludes on page 50 " the most promising approach to
unanticipated behaviour evolution is the integration of delegation
into statically typed class-based models. This is the approach
he pursues and designs Lava, an extension of delegation to Java.
>
> > 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").
What I meant here reiterates what I quoted above. Anyhow thanks for the
info.
>
>
> > 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)
>
Well Platonic perfection sounds like eternal beauty, static, not evolving.
For example Christopher Alexander mimicks Platonic thinking perfectly
well. Saint Exupéry's quotation sounds Platonic anyhow.Reading
The small prince I would never forget what he stated about love:
one is responsible for whom one captivates! What makes you think
that to love is to try to captivate someone! Something like I tried
persuading Günther to share our discussion!!!
And you saw his reaction! Well modern thinking refuses this trend
of thinking. Apples and bananas will never mix ...apples are from
temperate zone and bananas from tropical climates! So it is better
to evolve vertically being open and trying to understand the way
things are and at a higher level one understands that banana and
apple are fruit. In this level the understanding is possible. And the
fact one is tropical and the other is temperate may seem irrelevant.
And yet it is a mere possibility...
I'm rather a scientifc mind like Aristotle! Or like the theorists that bet
on evolutionary ideas. So I think that necessarily things are always
evolving....This process leads us to find states that Platonic thinking
describes as perfect, however a man who bets on experience will
always feel that there are still more infinitely perfect things to come....
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.
However using the concept of object, and forgetting about variables
and instances mimicks the perfection of the notion of thing. Simple
and convincing!
>
> > I was afraid of Lisp because it is atyped. Besides the fact it
> > doesn't feet my needs.
>
Sorry for the English errors....untyped and fit 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).
>
Yes, I realized this only in 1996! But underlying my viewpoint was
the need to be democratic. I mean I wanted every architect to design
with my ecodesign model. And so according to the experts in computer
science (among them my beloved Stephen Omohundro who also deals
with geometric learning algorithms!) one should for economic reasons respect the
environment created for C!!! And hence program in PCs!!!
>
> > 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.
It could have been...But what matters is that I suddenly was not
afraid of exploratory programming and I was forced to see how
Self worked ....If I didn't I was not faithful to scientific truth!
>
>
> 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)
>
Wonderful explanation!!I love it!
>
> > 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.
>
Honestly I do not agree! Anyhow I should consult my friend Erik Ernst.
I am sure he may help us to get to a consensus. I think the abstract
mechanism introduced by Bent Bruun Kristensen (he is the creator
of the abstract mechanism in Beta like the pattern and so on...)
complex associations would be nearer. If I remember well, he published
this paper in OOPSLA'95!!
>
> > [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....
>
By now I managed to read pages 40-48. See what happened. I have to
read very slowly detailed information to grasp its meaning. For me this
is awfully painful and violates the needs of the cognitive processes
linked to the right side of the brain. Especially when there are leaps
in the analytical thinking. Luca Cardelli fills everything like a continuum..
When I grasp the idea, I manage to read things at very fast
speed. If I read slowly my memory is not good, and so at the
end of a long paragraph I do not remember what I read!!!
See until 22 years old, I read too much...After that I only managed
to read Ulysses from James Joyce at the age of 33....Simply
because it is like music...What matters is what you read at the
moment...You do not have to remember anything...
>
> > 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.
Yes, by now I understand this. What I think makes things
difficult to read in his thesis is the diagrams...They are too
sequential to represent things that are rather hermeneutic and
hence circular....
> My conclusion is that I will keep using a prototype based
> language :-)
> Well intuitive I stick to the prototype based languages...
But how can I persuade a researcher at FAPESP (FOundation
of Protection To Research in Sao Paulo State) that may even
not know what object orientation is, that it is worth to
invest in prototype based languages....
I have not concluded my inquiries yet because nobody from
the prototype based community showed how design patterns
are better implemented in Self for example....
Dave, do you hear? The challenge is launched!!!
Now I am eager to read chapter 8 from Günther's thesis. I invite
you all to do the same. It is really intriguing He illustrates how
to use delegation to implement some design patterns.
Thanks Jecel and Happy Birthday to you!!!!Happy Birthday to
you!!! And that God may bless you and you may accomplish
all your desires! and have a very long life to see life on Mother
Earth become sustainable through the breakthrough of
prototype based languages!!!!
Albertina
>
> -- Jecel
--
.----------------------------------------------------------.
| Albertina Lourenci |
| PhD in Architecture and Urbanism |
| post-doctorate researcher |
| Laboratory of Integrated Systems University of Sao Paulo |
| Avenida Professor Luciano Gualberto, 158 Travessa 3 |
| CEP: 05508-900 |
| Sao Paulo Sao Paulo State Brazil |
| Voice: +55 011 818 5254 |
| Fax: +55 11 211 4574 |
.----------------------------------------------------------.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.selflanguage.org/pipermail/self-interest/attachments/20001127/3ffaa08c/attachment.html>
More information about the Self-interest
mailing list