This message from Doug Orleans clarifies the relationship between Demeter/Java and the SIGSOFT '96 paper http://www.ccs.neu.edu/research/demeter/biblio/context.html Date: Tue, 15 Oct 1996 23:48:44 -0400 (EDT) From: Doug Orleans (edited) Demeter/Java is *not* an implementation of contexts; it is an implementation of visitors, from which the context idea generalizes. Because the visitor idea is a specialization of contexts, the implementation makes some optimizations that would not (and could not) be made in an implementation of general contexts. Some of these optimizations are reflected in the syntax of the Demeter/Java language; most of them are only reflected in the generated Java code. ------- Crista Lopes' question: 1. What's the type of the special variable "context"? Can it be manipulated directly by the receiver object? ------- In Demeter/Java the visitor object is doing the visiting, and the host object is being visited. Because the before/after methods are attached to the visitor object, you refer to the visitor as "this" and the host as "host" (which is actually passed in as an argument). With context objects, the methods are conceptually (if not implementationally-- is that a word?) attached to the receiver object, so you use "this" to refer to it, and "context" to refer to the interceding context object. Side note: usually the reference to "this" is implicit; if you're getting a member value or function, you just leave out the word "this" altogether (just as in C++ or Java). In the paper, you would leave out the word "context" as well; the members of both the receiver and the context are considered to be in the same namespace. (There was some disagreement as to which should have precedence-- I don't remember what was decided.) It may help to think of it in terms of a multi-method. You just have a free-standing function with two arguments: visitor and host (or context and receiver). Nothing is attached to anything, these are just two arguments being passed to a function; this also means that member references must explicitly refer to the object. This idea is reified by the AP/STklos implementation. ---------- Crista Lopes' question: 2. If the receiver object contains a non-empty method m and the corresponding context object redefines m, which method is executed? Both? Or is the composition overriding by default? ---------- To answer your second question: I think you can only manipulate "context" directly in methods defined in the context object itself; the receiver has no way of getting to it. The idea is that the receiver is some legacy code, and you're bringing in a context object to change the behavior in some way that wasn't anticipated when the receiver code was written, and without having to rewrite it. > 2. If the receiver object contains a non-empty method m and the > corresponding context object redefines m, which method is executed? > Both? Or is the composition overriding by default? This case does not even arise in Demeter/Java. The only methods that are used in the visitor/host relationship are "before" and "after", which are only defined on the visitor; they are called directly from the "XXX_traverse" method attached to the host (which is generated from the traversal directive). If the host happens to define "before" or "after" methods, they don't come into the picture at all. If a visitor (or more likely, a set of visitors cooperating on a single traversal) provides before methods for both a superclass and a subclass, only the subclass one is called, i.e. overriding inheritance. I could uncomment about 5 lines in the demjava code to make it use incremental inheritance. > 4. Is the extension o::+c incremental or is it just an assignment? > That is, what is/are the context object(s) when I do > o::+c1; o::+c2; > For now the paper uses overriding semantics. > Demeter/Java does not have this. In AP/STklos, you can add a list of visitors, but it has to be the last expression in the before/after method: (define-visitor :params (part) :locals (cv sv) :methods ((before (set! cv (make :target )) (set! sv (make :target :part part)) (add-visitors cv sv)))) If you did (add-visitors cv) (add-visitors sv), only the second one would be added, i.e. overriding semantics. > 5. I didn't see any example of behavior _evolution_. All the examples > are about different behaviors, with no relation to _evolution_. > You can evolve behavior by adding more context objects to a traversal. > First you want to count -> CountingVisitor > Then you want to add -> SummingVisitor > Then you want to print the running average: You package the > CountingVisitor and SummingVisitor int an AverageVisitor > and attach all three on them to the same traversal. I think the idea is that the behavior evolves from doing nothing to doing something; you're adding this new functionality, namely computing the average salary of a composite object structure, without having to add any methods to the classes involved in the composite. > 6. What context objects suggest is that classes become instantiable > interfaces and implementation is grouped in "context classes" that may > contain implementation of different "interfaces". How do you identify > context classes? > The context classes define the "activities" of the application > independent of the interconnections. As far as attachment to > call is concerned, context classes correspond to wrappers in Demeter/C++. The advantages of context classes over wrappers (and transportation variables) are all the standard ones of OO-programming: encapsulation (of the behavior involved in doing an operation), inheritance (you can re-use most of the behavior of another context class and only change the things you need to change), and polymorphism (you can choose which behavior to use in a particular operation at run-time). --Doug ======================= Post discussion: Karl Lieberherr writes: > I feel that > > Demeter/Java is *not* an implementation of contexts > > is too strong a statement. I would say it is an implementation of > context objects attached to calls only with the following proerties: > > 1. The calls modified by the context objects must come from traversal > specifications. > > 2. There is a special treatment of before and after methods. > > Do you agree with this perception? Doug Orleans responds: Well, there's not only "special treatment" of before and after methods, but in fact these are the only two methods that use the context relation. And even that's sort of wrong, because they behave as if attached to the visitor (context) rather than the host (receiver), which was one of the main points of the context paper. If I were implementing contexts, I would probably do it very differently; what I implemented were visitors & traversals, and contexts are a generalization of that, but there's a big gap between the two. It's sort of like saying that Pascal is an implementation of an object-oriented programming language, except it's restricted so that there are no classes or objects. Karl Lieberherr agrees.