>From lopes@parc.xerox.com Wed Aug  6 16:46:50 1997
>To: Boaz Patt-Shamir <boaz@ccs.neu.edu>
>Cc: Cristina Lopes <lopes@parc.xerox.com>, lieber@ccs.neu.edu, dem@ccs.neu.edu
>Subject: Re:  traversals
>
>
>
>I know very well what your definitions are. My comments
>simply point out that there are other alternative meanings that are as
>intuitive as the ones you have. That is bad, from a language design
>point of view. (this has nothing to do with your algorithms). 
>
>For example, suppose I'm designing a language in which I define the
>construct 
>
>ifnot <var> then <expr2> else <expr3>
> to mean 
>"if var is not bound yet, execute expr2; else execute expr3"
>
>Plausible, right? But very confusing, because another possible and
>intuitive meaning is
>"if var evaluates to false, execute expr2; else execute expr3"
>
>There's a language design principle, mentioned by Wulf, which is "the
>law of least astonishment", which states that "things which are
>conceptually similar ought to behave similarly."
>
>This is my reason for disliking the extended traversal language 
>of Demeter: the traversal language leaves plenty of room for other
>interpretations at least as intuitive as the ones you define so
>carefully in the paper.
>
>> This may be true, but it's a matter of taste: confusion is, in many
>> cases, in the eyes of the beholder. A convincing example is required
>> to substantiate such a claim.
>
>For example, the path Karl also thought confusing (wrt your
>example in the paper):
>- A E B1 A C1 D F A E B2 A C1 D
>
>It might be argued that the second part of the path, starting at the
>second A, should not be visited, because there is no Bi Ci between the
>second A and the second D.
>
>Looking at the strategy, it seems very natural to interpret it as "go
>from A objects to D objects such that there is a Bi Ci between any A
>object and any D object.
>
>I know this is not the current meaning. I'm just arguing that there is
>this other intuitive interpretation that introduces some confusion in
>programmers' heads. (I know this is true, because I have explained
>Demeter to a lot of people, and I found out that everyone gets the
>simple traversal directives, but a lot of people (especially smart
>people) get really confused when it gets to explaining "via" and
>"through", because they can come up with these alternative meanings)
>
>Now, a certain level of confusion can be justified if the result is
>_really_ useful. But as Karl said, traversals that make use of
>traversal histories are rare. So why bother to include them in the
>language in the first place? Besides not being very useful, they make
>the implementation more difficult.
>
>> > 2) you cannot reach arbitrary object paths, which, ultimately, should
>> 
>> This is false. Any object path is easily programmable by making the
>> stratgey graph explicit enough (e.g., let each stratgy edge represent
>> a single class graph edge by excluding all others using "bypassing").
>
>Consider the strategy you suggest:
>S = ((Book, null), Book, null)   (I'm using your form)
>
>How can we traverse exactly only the instance of Book whose title is
>"Gone with the wind"?
>When you talk about object graphs, this is a reasonable demand.
>
>Using Demeter's traversal language, you can't identify specific
>instances. You can do it only with code in the wrappers, not with
>traversal specifications.  What Demeter's traversal language lets you
>express is (fairly) arbitrary object traversals based on the history
>of the types of the traversed objects. This is a kind of predicate
>for selecting the visited objects.
>
>There is a way of doing this in general, although not in succinct
>form, and it's called SQL. SQL allows you to express _any_ object
>traversals, and exactly the objects you want.
>
>> > 3) in general, your semantics prevents you from doing separate
>> >    compilation of strategies and classes. 
>> > 
>> 
>> I'm not sure what exactly do you have in mind. Please explain.
>
>I confess I was referring to the old Demeter. It seems to me that your
>algorithm is a step into separate compilation, since you have traversal
>graphs as parameters to the traversal methods. That's the way to go.
>
>There may be still some problems, though. I will have to understand
>your algorithm better. Let's talk about it next time I go to Boston.
>
>For example, if step 4 of algorithm 2 is implemented in such a way
>that the structure of the superclasses is hard-coded, you're in
>trouble, because if you change the superclass, we need to recompile
>all its subclasses.
>
>In order to avoid this problem, you need to make another assumption,
>which is necessary for step 5: you need to be able to invoke objects
>whose handles are known only at run-time - note that this is much
>stronger that the introspection you state you need in the beginning of
>section 5.2. How would you do it for C++? These are engineering
>details that make the difference between being able to do separate
>compilation or not.
>
>(Question: Why don't you just call super.traverse(T, TG), instead of
>flatting the calls into the subclass?)
>
>I was about to respond to the remark in page 6, but I realize I
>already spent 2 hours writing this mail!!!
>
>This is a very interesting discussion. Next time I go to Boston,
>besides doing my defense, I volunteer to do a Demeter seminar to talk
>about this.
>
>-Crista
>