Hi Mira:

>For me this remains still an open problem. Let see how far we can go
>with on or the other alternative.

Thank you for your view. Here is what I think we should do.
Our current language allows us to program in both styles.
If we want to follow Doug's style we can simply try to write
only "from Source to *" strategies in APPCs.
If we want more flexibility we can use any strategy we like.

David was pointing out that he would like to have complete symmetry between
concrete class graphs and interface class graphs.
This points in the direction that we want general strategies
in APPCs, not only "from Source to *".

-- Karl

>From mira@informatik.uni-siegen.de Thu Nov  5 04:27:05 1998
>Subject: Re: Doug's simplifcation
>To: lieber@ccs.neu.edu (Karl Lieberherr)
>Date: Thu, 5 Nov 1998 10:26:53 +0100 (MET)
>From: "Mira Mezini" <mira@informatik.uni-siegen.de>
>Cc: dougo@ccs.neu.edu, jayantha@ccs.neu.edu, johan@ccs.neu.edu,
>        lieber@ccs.neu.edu, lorenz@ccs.neu.edu, mira@informatik.uni-siegen.de
>
>> He feels that there is duplication between strategies and interface class graphs.
>> He proposes that we make the interface class graphs so minimal
>> that for a traversal APPC the traversal goes from the sources
>> to everywhere.
>> 
>> In other words, for a traversal style APPC the traversal is always
>> go everywhere.
>
>This sounds good. I have a small problem with that. 
>
>"make the interface class graphs so minimal"
>
>This works fine with small examples. But, what is when we writte real
>programs? We would be forced to have tinny APPCs in order to keep the
>ICG minimal. Thus, for larger projects, we would end up with A LOT
>of small APPCs since each APPc is reduced in an adaptive method. 
>That makes programs hard to understand and maintain.
>
>In general we would like may be to pack more behavior into one APPC, only
>a part of which is traversal driven.
> 
>For me this remains still an open problem. Let see how far we can go
>with on or the other alternative.
>
>- Mira
>
>