The nature of music was Re: [Fwd: prototypical analysis and design]
Albertina Lourenci
lourenci at lsi.usp.br
Wed Nov 22 18:19:19 UTC 2000
Günter Kniesel wrote:
Hi Gïnther:
Well if you are not worried in saving Mother Earth,
I am. I need OOP to build sustainable cities. I know most computer
scientists prefer to build interplanetary stations when life on earth
will not be possible anymore. Please don't take this as aggressive,
but all my life orbits around this concern.
Otherwise, the brightest computer scientists seem
eager
to see the take-off of the prototype paradigm. And gracefully you made
public electronically all you do. I am asking for a grant to have facilities
that will enable me to make all that I do available at the Internet.
And above all I am an artist. I have just finished
writing
something about hermeneutics. Music is the most hermeneutic art.
So for me a discussion like the one I am proposing is like mimicking
a symphony. Why can't we play together?
In real music, specially contemporary music
dissonances are welcome. So why to get worried? Musicians
say that dissonances are more difficult consonances.
I read through your response fast. I have to
go
swimming now as part of my health recovery. All the information
is my head is fuzzy, so I cannot agree or disagree if you said
delegation is better or not than patterns. As far as I know I have to
read at least your whole chapter 8 Applications (165-178) and
many more papers about design patterns to conclude something.
You would help my poor brain to stay fit if you agreed in cooperating.
Please be gentle. There is no better way to learn than discussing and
making errors. Randy Smith made a good contribution to this through
his Distributed tutored video instruction. I loved it and it emphasized
the musical nature of Self.
As soon as I can, I will dialogue with you all about Günther's statements.
Best wishes
Albertina
> Dear all,
>
> > Bharat Bedia wrote:
> >
> > > Firstly my apologies if people find
> > > this thread off topic. If they can point me to an appropriate place
> > > then I'll glad take the conversation elsewhere.
>
> My appologies too, to anyone not interested in this discussion.
> However, since I've been cited in a way that lends itself
> to being misinterpreted I have to make a few statements
> for the people who read the previous mails.
>
> Any followup message will be sent just to those who
> participat(ed) in this discussion.
>
> By the way, Albertina, there was no point in asking the whole
> world what I could have possibly meant with a certain passage
> of my PhD thesis. Just send ME your questions, I'll be happy to
> answer them.
> You can still make your conclusions public if you feel the need.
>
> Guenter
>
> -----------------------------------------------------------------------
> Albertina Lourenci wrote:
> >
> > Günther Kniesel seems to be making a good job in his Ph.D Thesis
> > (Take a look at the Darwin project. It is an extension of Java
> > supporting a
> > form of delegation, so you get both classes and delegation.
> >
> > http://javalab.cs.uni-bonn.de/research/darwin/darwin_eng.html
> >
> > ... snip ...
> >
> > And what is best he argues that the complexity of many patterns
> > is not intrinsic, it can often be seen as resulting from poor language
> > support. (Kniesel, Ph.D thesis page 165 at the bottom).
> > So I invite him to join our discussion and show to us how
> > delegation implements the design patterns better.
>
> Well, the GOF itself mentions several times the problems involved
> in implementing patterns like strategy, state, etc and
> refer to Self as an elegant alternative. In my phd thesis you can
> compare the code in the implementation chapter to the code in the
> applications chapter.
>
> If you have delegation you can implement an "overriding decorator"
> which provides behaviour that will take effect in the
> context of the "decorated" object by essentially one keyword:
>
> class Decorator extends Whatever {
>
> protected final delegatee Decorated _decorated;
> ^^^^^^^^^
> Decorator( Decorated d) { _decorated = d }
>
> // ... any methods
>
> }
>
> Decorator will automatically be a subtype of Decorated,
> locally unimplemented messages will automatically be delegated
> to objects referenced by _decorated and
> methods in Decorator will override methods from Decorated.
> This works even if there are no hard-coded hooks in Decorated
> to enable such an extension. *Unanticipated* extension is
> not possible with patterns.
>
> If you do not have delegation as a first class language feature
> you have to anticipate the extension and hand-code anything that
> is described in the "implementation" chapter.
> And that is substantially more than what is discussed in most
> "delegation-like" patterns. For instance, the problem of direct
> access to public variables is usually ignored.
>
> I'd say that the step
> - from "many, many lines of code all over your application" to
> "one keyword" and
> - from "imposible" to "possible" in the unanticipated extension
> case
> is a significant simplification ;)
>
> > Jan Bosch wrote an interesting article "Design Patterns as Language
> > Constructs" in Journal of Object Oriented Programming May 1998
> >
> > He identifies four problems associated with their implementation
> > using conventional object-oriented languages. First, the traceability
> > of a design pattern in the implementation is often insufficient; the
> > design pattern is lost. Second, because several patterns require an
> > object to forward messages to other objects to increase flexibility,
> > the self problem often occurs. Third, because the pattern
> > implementatin is mixed with the domain class, the reusability
> > of pattern implementations is often limited. Finally,
> > implementing design patterns may present significant
> > implementation overhead for the software engineer.
>
> I use to call patterns like state, strategy, decorator, flyweight,
> etc "split object patterns". They share the basic idea of splitting
> one conceptual object into (at least) two implementation objects
> that should act like one. For split object patterns, delegation
> is the natural implementation technique. It eliminates all the
> shortcommings addressed by Jan Bosch.
>
> > > > At the right moment based on Günther Kniesel's PHD thesis
> > > > I am trying to figure out why he argues that delegation is
> > > > far better than design patterns.
>
> I did not say that delegation is better than (any) design patterns.
> Obviously delegation is completely unrelated to tons of patterns
> (e.g. singleton, template method, factory method, etc).
>
> What I say and mean is that delegation is the best way to implement
> split object patterns. Put differently, it is not an alternative to
> the patterns themselves, because it preserves their essential ideas,
> but it simplifies their implementation up to the point where it
> becomes trivial.
>
> With delegation the implementation of many different patterns
> is so similar (because all the "simulation noise" vanishes)
> that it becomes obvious that all split object patterns
> are essantially instances of two basic cases:
> - unanticipated, identity-changing extension (decorator-like)
> - anticipated, identitiy-preserving splitting (strategy-like)
> (See the "Applicatons" chapter of my thesis).
>
> -------------------------------------------------------------------
> Albertina Lourenci wrote:
> >
> >
> >
> > Hi Thomas:
> > Well I am overstressed and I may be coopting what I read to tune with
> > what I expect but let us examine this passage from Günther's PhD
> > thesis (page 49-50)
> >
> > Thus the application of design
> > patterns for simulating BEHAVIOUR EVOLUTION CAN
> > IMPEDE REUSE (OF EXISTING CODE AND DESIGNS)
> > AND COMPLICATE PROGRAM MAINTENANCE, achieveing
> > \the opposite of what is widely regarded as a main benefit of OOP.
> > Therefore, extension of traditional class-based object models
> > by a mechanism for unanticipated behaviour evolution is
> > ultimately required.
> >
> > I invite Günther to throw light in this passage. But I interpreted
> > as delegation is better than design patterns.
>
> Just shift the stress in your citation an you'll get it:
>
> > Thus the application of
> > DESIGN PATTERNS FOR SIMULATING BEHAVIOUR EVOLUTION
> > can impede reuse ...
>
> That's it: I do not refer to patterns in general but
> to PATTERNS FOR SIMULATING BEHAVIOUR EVOLUTION.
> Or, more general, to "split object patterns".
>
> -------------------------------------------------------------------
> > Thomas Kuehne <kuehne at informatik.uni-kl.de> wrote:
> >
> > Hi Albertina,
> >
> > as far as I know Günther (I know him) does not claim that
> > delegation is better than design patterns.
> > I reckon he says that with delegation most design patterns
> > are easier to implement.
>
> Thanks Thomas. That is just what I meant.
>
> Regards
> Guenter
>
> -----------------------------------------------------------------------
> Guenter Kniesel e-mail: gk at cs.uni-bonn.de
> Computer Science Department III Phone: (+49-228) 73-4511
> University of Bonn Fax: (+49-228) 73-4382
> Roemerstr. 164
> D-53117 Bonn Office: A118
> ----------------- http://www.cs.uni-bonn.de/~gk/ ------------------
--
.----------------------------------------------------------.
| 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/20001122/e1ec1e82/attachment.html>
More information about the Self-interest
mailing list