From dougo@ccs.neu.edu Mon Sep 8 18:53:01 1997 Received: from vega.neu.edu (vega.ccs.neu.edu [129.10.115.77]) by amber.ccs.neu.edu (8.8.6/8.7.3) with SMTP id SAA08373; Mon, 8 Sep 1997 18:52:58 -0400 (EDT) Received: by vega.neu.edu (SMI-8.6/SMI-SVR4) id SAA03208; Mon, 8 Sep 1997 18:52:42 -0400 Date: Mon, 8 Sep 1997 18:52:42 -0400 Message-Id: <199709082252.SAA03208@vega.neu.edu> From: Doug Orleans To: Karl Lieberherr Cc: dem@ccs.neu.edu, lopes@parc.xerox.com Subject: Re: explicit strategy rule In-Reply-To: <199709041317.JAA06366@stockberg.ccs.neu.edu> References: <199709041317.JAA06366@stockberg.ccs.neu.edu> X-Mailer: VM 6.22 under 19.15 XEmacs Lucid X-Face: (4D-osoq?}7M3\EgvbWKo Crista still thinks that the Explicit Strategy Rule should be the default. > Do you have examples which show that this would be too restrictive? > Show some strategy/class graph combinations. For example, for > the strategy graph > > {A->B > B->C} > > why is it useful to have a class graph which has an A between B and C. How about this: NestedShape : Circle | Square *common* NestedShape. Now, say you want find all circles that are inside squares: NestedShape { traversal allCirclesInsideSquares(SquaredCircleVisitor) { via Square to Circle; } } This will go to all Circles that are inside Squares. This will also go to outermost Circles, but once we have the capability to qualify a wrapper with a particular strategy edge, we can tell the difference: SquaredCircleVisitor { before Circle : NestedShape->Square (@ println("outermost circle"); @) before Circle : Square->Circle (@ println("squared circle"); @) } If this were an Explicit Strategy, i.e. { NestedShape -> Square bypassing { NestedShape, Square, Circle }, Square -> Circle bypassing { NestedShape, Square, Circle } } then we could only visit shapes whose outermost shape was a square. I'm sorry this example is so contrived, but to be honest I don't have much intuition when it comes to class graphs containing cycles. --Doug