Re: [cme-dev] Visiting Concerns

[Harold Ossher <ossher@xxxxxxxxxx>]

Hi Philip,

It's really interesting that you raised this. There is, as you observed, no
visitor support for concern models. This is in large part because we always
tend to think of composition as a better realization of visitors than the
usual approach. Here's how it would work, illustrated with your example.

Typically, the visitor pattern is used to extend an interface - to add some
new capability across an inheritance hierarchy (like the concern model),
implement it separately for selected specific classes, and use dispatch to
pick the right implementation, There's also the actual traversal, but let's
ignore that for a moment.. So, using a composition approach, you write an
extension to the interface, to the top-level abstract class (to do nothing)
and to the classes you actually want to extend. These classes can be
top-level classes, or inner classes within a containing "visitor" class, in
your own project. In your case:

public interface ConcernModelElement {
      public void collectAdvice(Collection c);  // Additional method
}

public class AbstractConcernModelElementImpl implements
ConcernModelElement, org.eclipse.cme.conman.ConcernModelElement {
      public void collectAdvice(Collection c) {} // Default implementation
}

public class Advice implements ConcernModelElement,
org.eclipse.cme.conman.Advice {
      public void collectAdvice(Collection c) {  // Specific implementation
            c.add(this.getDefinition());
            // c.add(this.getAdviceArtifact);  There is not a special
method getAdviceArtifact, but this is how you'd use it if there were.
      }
}

Now you can compose this extension with ConMan (or the cme jar), and call
collectAdvice like any other method. So you would iterate over the elements
you care about, calling this method. The same, or separate, extensions
could add other methods.

Conceptually, this approach has some advantages over the standard
implementation of visitor, such as the ability to add methods with a
variety of parameters and return types and avoidance of double dispatch. It
doesn't handle the traversal, through. You could do that by implementing
the collectAdvice() method for GroupImpl, the top-level collection in the
concern model hierarchy, to iterate over the elements. Unfortunately, there
is no way to make this generic across all extensions, as the usual visitor
pattern does, because a specific method name is involved (rather than a
visitor object).

Unfortunately, we don't yet have the tool support to make the composition
approach really convenient (some classpath manipulation, integration of
composition with the Eclipse build process, perhaps some refactoring/code
generation to help set up the structure, ...). Still, I'd be interested to
hear your thoughts on this approach, and if you have time and are feeling
adventurous, we can help you set this up by hand using the lower-level
composition support we do have. Together we'd learn something about what is
really needed to support this well. (We might hit some bugs or limitations
in the course of this, which we'd be happy to work on, but our time is
limited so we should discuss your time constraints.)

Regards, Harold



                                                                           
             Philip Quitslund                                              
             <pq@xxxxxxxxxx>                                               
             Sent by:                                                   To 
             cme-dev-admin@ecl         cme-dev@xxxxxxxxxxx                 
             ipse.org                                                   cc 
                                                                           
                                                                   Subject 
             12/13/2004 05:48          [cme-dev] Visiting Concerns         
             PM                                                            
                                                                           
                                                                           
             Please respond to                                             
                  cme-dev                                                  
                                                                           
                                                                           




Hi all.

Forgive me if this is obvious (and it probably is!) but I'm puzzling over
how to
best traverse the structure of Concerns.  What I'm driving at is a way to
take a
  Concern and build my own abstract representation.  I was expecting some
kind
of visitor scheme but haven't found anything...

As a simple example, suppose I wanted to collect all the AdviceArtifacts in
a
Concern.  I'd like to avoid code that looks like this:

 /* final */ Collection adviceCollector = new ArrayList();

 ConcernModelElement cme =
  /* ProxyConcernModelElement */ pcme.getConcernModelElement();
 if (cme instanceof ConcernImpl) {
  ConcernImpl concern = (ConcernImpl)cme;
  QueryableRead elems = concern.getElements();
  for (Iterator iter = elems.iterator(); iter.hasNext();) {
   Object o = iter.next();
   if (o instanceof AdviceUnit) {
    adviceCollector.add(((AdviceArtifact)o).
     getAdviceArtifacts());
   }
   ...
  }
  ...
 }

preferring something more like this:

cme.accept(new ConcernVisitor() {
  void visit(AdviceUnit advice) {
   adviceCollector.add(advice.getAdviceArtifact());
  };
 );

(Admittedly this is an overly simple example, but you get the idea.)

What's the best way to programmatically explore the structure of Concerns?

Any help would be greatly appreciated.  Thanks!



-phil





_______________________________________________
cme-dev mailing list
cme-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cme-dev