Hi Mira:

>From mira@ccs.neu.edu Tue Oct 21 15:41:37 1997
>Subject: Re: packaging adjustments
>To: lieber@ccs.neu.edu (Karl Lieberherr)
>Date: Tue, 21 Oct 1997 15:41:31 -0400 (EDT)
>Cc: dem@ccs.neu.edu
>
>Hi Karl:
>
>Here is my response to your mail on packaging adjustments:
>
>> Hi Mira:
>>
>> from your presentation it became clear that
>> Rondo and Demeter have many connections.
>>
>> Let me focus on one of them: adjustments and visitor methods.
>> The managing of adjustments is handled differently in both
>> systems.
>>
>> In Rondo you have adjustments and you express which classes
>> they modify when certain behavior is desired.
>>
>> In Demeter/Java (DJ) we package adjustments together into
>> visitor classes with init, return, start, finish,
>> before, after and around methods.
>> Our visitor classes are self-contained in that they handle
>> one complete behavior unit.
>
>I agree with your description of the differences in managing
>behavior modifications (I prefer this term as opposed to
>`adjustments' for generally describing the definition of behavior
>variations in order to distinguish from adjustments as language
>constructs as they are used in Rondo).
>
>> What is your view of packaging adjustments together?
>
>Currently there is no packaging feature included in Rondo.
>When defining the syntax of Rondo, I initially had a construct
>called `AdjustmentSet', which purpose was exactly to provide
>a construct for packaging together adjustments specified to
>modify different classes, but involved in specification of
>the same behavior modification.
>
>However, I left that construct
>out of the current syntactic definition of Rondo, since I
>felt that it didn't bring anything new. Well, it has definitively
>advantages from a software engineering point of view. But,
>given the current infrastructure of the definition layer
>of a Rondo programm, the information about which adjustments
>are related in terms of collaboratively specifying a certain
>behavior variation is contained in the managers and can be
>filtered out, if needed.
>
>That's why I didn't inculded an
>explicit packaging construct -- I wanted to keep the syntax
>as simple as possible. However, if the experience of using
>Rondo would show that an explicit packaging construct would
>be valuable, it can be added very easily on top of the
>existing model -- it is orthogonal to the existing constructs
>of Rondo.

Interesting history.

>
>Notice that even in the presence of the packaging
>construct, I would like (my intuition tells me)
>to keep splitting a certain behavior variation in adjustments
>each specifying how the behavior variation affects a single class
>(or in general behavior definition module, i.e. class or adjustment)
>in the existing functionality.
>
>I somehow dislike the idea of gathering
>methods (before, after, around, ...etc) which reimplements methods
>from different classes in the existing class graph in a single
>visitor class. I feel like this may require editing of existing
>visitor classes when you add e.g. some new classes in the
>`base' class graph. But, let us discuss about that.

Yes, you are right that we might have to edit visitor classes
but only if the addition to the `base' class graph modifies
the behavior expressed by the visitor. Then it is natural
to have to edit the visitor.

As Doug points out below, we can also use visitor subclassing.

>
>> In your talk you mentioned that we could create a combined language
>> by taking some concepts from both.
>> What do you think would best fit into
>> DJ?
>
>Well, I am not really comfortable with answering this question right now.
>I would have preferred to have more time to deeply study the connections
>and the differences of both models in general and the features of
>DJ in particular. However, let me write down my
>current (vague) thoughts and continue the discussion as my
>understanding enhances.
>
>I have the impression that the way behavior modifications are
>managed in Rondo could be valuable for DJ, may be simplifying
>a bit the design? I somehow feel uncomfortable with having
>several different kinds of methods -- `before', `around', `after',
>`start', etc. Are they really necessary? What is your experience
>with using DJ? Are students comforable with that?

I understand that my question was a little premature.
Our goal was to stay close to Java and since visitor objects
are objects like other objects we don't have to introduce
something too different. Our experience is that Java programmers
like this closeness to Java for expressing their behavior modifications.

>I'd like to emphasize that personally I don't have a
>deep understanding. I need a fast course in DJ urgently.
>And I definitevely need to read the paper by Seiter & Palsberg &
>Lieberherr. I left my copy of it in Siegen. Could you provide
>me with an electronic copy of the paper?
>
>On the orther side, I think that the strategy specifications
>extensively used in Demeter in general and in DJ in particular
>would be indispensable for Rondo. They would help in specifying
>at a higher level how a special behavior (or behavior variation)
>should propagate through a structure of collaborating objects
>(classes). The purpose is to succinctly say that if an object
>of class X adjusts its behavior according to the behavior
>variation Y because the event Z got raised than also objects
>X1, X2, ... which are somehow related to X should adjust
>themselves.
>

Yes, I can see how that is useful for Rondo.

>
>> I would like to collect the discussions about Rondo and Demeter in:
>> http://www.ccs.neu.edu/research/demeter/related-work/Rondo
>> Is this ok with you?
>
>As I already wrotte you, you are welcome to do so.
>
>
>- Mira
>
>
>
From dougo@ccs.neu.edu Tue Oct 21 15:50:31 1997
From: Doug Orleans <dougo@ccs.neu.edu>
To: Mira Mezini <mira@ccs.neu.edu>
Cc: lieber@ccs.neu.edu (Karl Lieberherr), dem@ccs.neu.edu
Subject: Re: packaging adjustments

Mira Mezini writes:
 > I somehow dislike the idea of gathering
 > methods (before, after, around, ...etc) which reimplements methods
 > from different classes in the existing class graph in a single
 > visitor class. I feel like this may require editing of existing
 > visitor classes when you add e.g. some new classes in the
 > `base' class graph. But, let us discuss about that.

You could always add (meta-) adjustments to the visitor classes as new
behavior modifications are needed-- this is the analog of the current
answer in Demeter/Java, which is to add subclasses to the visitor
class that extend/modify its behavior.

--Doug

-- Karl