Hi Johan and Mitch: I agree with you that flattening should carry the day. But I don't see two principles at odd. An object of the subclass will have only one l. So why would we want to traverse both l's? From your answer I conclude that Java supports overriding of data members with subclasses. And that Demeter/Java does not do this now but is a feature which we want to support. Doug, please can you add this to the BUGS list? -- Karl From johan@ccs.neu.edu Tue Oct 14 11:50:16 1997 From: Johan Ovlinger To: lieber@ccs.neu.edu CC: dem@ccs.neu.edu Subject: Re: overriding of instance variables I am making this up as I go along, but I believe: That shadowing of instance variables works in the expected way, ie subclasses override the definition. I have given thought to how this applies to traversal specs, but I have forgotten if I implemented it correctly for TAO. There are two principles at odds here: Flattening takes the traditional OO view of overriding subclassing. vs Traversals are more natural to see in the light of extending functionality, where both s would be traversed. I think that Flattening should carry the day, as it is a shorter principle to describe. Both Doug's and my implementations are incorrect. I doubt that the parser generated will work for this kind of object, and as your example shows the getters and the constructors are also wrong. My TAO implementation may be closer to Traversals approach, in that if memory serves, it will traverse both s, going to U for one and V for the other. Joahn From wand@ccs.neu.edu Tue Oct 14 12:02:21 1997 To: Johan Ovlinger CC: dem@ccs.neu.edu Subject: Re: overriding of instance variables JO> There are two principles at odds here: JO> Flattening takes the traditional OO view of overriding subclassing. JO> vs JO> Traversals are more natural to see in the light of extending JO> functionality, where both s would be traversed. JO> I think that Flattening should carry the day, as it is a shorter JO> principle to describe. Both Doug's and my implementations are JO> incorrect. I doubt that the parser generated will work for this kind JO> of object, and as your example shows the getters and the constructors JO> are also wrong. My TAO implementation may be closer to Traversals JO> approach, in that if memory serves, it will traverse both s, going JO> to U for one and V for the other. Hmm, so adding new subclasses may lead to a failure of adaptivity?!! Verry interesting! --Mitch Hi Johan: What is Java's and Demeter/Java's policy on overriding of instance variables? Consider: A = B. B : C *common* U. C : D *common* V. D = . U : V. V = "v". Main = . Does Java allow this? Is the l of a D-object of class V? Should Demeter/Java allow this too? Currently we get a compilation error. -- Karl demjava -tracevis -displayvis -printvis -copyvis -equalvis -outputdir ./gen -code -grammar program.cd program.beh CLASSPATH=./gen:$CLASSPATH javac -J-mx32m -d ./gen -depend -deprecation gen/A.java gen/ASCII_UCodeESC_CharStream.java gen/B.java gen/C.java gen/CopyVisitor.java gen/D.java gen/DisplayVisitor.java gen/EqualVisitor.java gen/Main.java gen/ParseError.java gen/Parser.java gen/ParserConstants.java gen/ParserTokenManager.java gen/PrintVisitor.java gen/Token.java gen/TraceVisitor.java gen/U.java gen/UniversalVisitor.java gen/V.java gen/__Subtraversal.java gen/C.java:4: Method redefined with different return type: V get_l() was U get_l() public V get_l() { return l; } ^ gen/D.java:4: Variable 'l' is used twice in the argument list of this method. public D(U l, V l) { ^ 2 errors make[1]: *** [gen/compile] Error 1 make: *** [gen/Main.class] Error 2