GraphDependencies and completion

[Vicente-Arturo Romero-Zaldivar]

On 10/17/2015 01:41 AM, Andreas Lundblad wrote:
> On Fri, Oct 16, 2015 at 03:33:58PM -0700, Vicente-Arturo Romero-Zaldivar wrote:
>> On 10/16/2015 02:17 PM, Maurizio Cimadamore wrote:
>>> Would a delegation model work for problem 2? I.e. the dependencies
>>> completer could be a 'spy' completer that did its own bit of logic
>>> and then delegated to the completer originally installed (which
>>> could be a real completer or the null completer).
>> I also thought about this, but IMO the model could be more general.
>> I mean it doesn't seem to be necessary to stablish an order between
>> the dependencies completer and the "original" completer. It seems to
>> me like they can be executed in any order thus effectively working
>> as "event listeners". This could imply having a list, or set if you
>> want to enforce uniqueness, of completers instead of only one
>> completer.
> If I understand you correctly, you're suggesting something like
>
>      symbol.completer = dependencies.wrapCompleter(someCompleter);
>
> Jan suggested this as well. The drawback is that there are ~20 writes to the symbol.completer field, two of which are inside Symbol that doesn't have a reference to the context.

I guess that this is what Maurizio is also proposing. In theory this 
model can work but it imply an order: the dependencies completer will 
always be executed before the "original" completer. I believe that the 
order is not important here and that a symbol can in general contain a 
list of completers which can be notified of events. Different completers 
don't need to know about or affect other completers in the list.

Vicente

>
> -- Andreas