[nem-en] Completion thoughts

NoiseEHC NoiseEHC at freemail.hu
Thu Jun 1 16:23:02 CEST 2006


As a side note there is a suggestion (note that I have no idea about the 
completion code):
1. We should decouple the completion logic from the compiler as much as 
possible:
- that way it will be less likely that some hack in the completion logic 
will break the compiler (as the latter is the more important IMHO)
- we could compile two versions of the source (with or without 
completion/syntax coloring/code analysis baggage)
2. We should create some more or less nonvolatile interface to the stuff 
so when compiler internals change we would not change the IDE editors. 
IMHO since currently we have only 2 editors I think we can assume that 
we will rather do the extra work to remain in sync with the Nemerle SVN 
than to block developing the compiler. All in all, the compiler has a 
higher preference than the interface to the completion engine.
3. The idea is that we should define some extra interfaces which shall 
be implemented by the compiler internal classes and the IDE's should use 
only these interfaces. Of course if it would be a subset of the internal 
interfaces we should not over engineer the stuff and just use the 
internal one. But in cases when the completion engine requires some 
filtering and caching then we would split this logic to a partial class 
or simply to an #ifdef. Another option is to define some macros which 
compile to nothing in case of a compiler build without the completion 
engine.
So here is a hypothetical example (and keep in mind that I have no idea 
about the completion code):
interface ICompletionClass {
  PublicMethods : List<ICompletionMethod> {get;}
}

class InternalCompilerClass : ICompletionClass {
...
  [JustForCompletion]
  _CachedMethodList : List<ICompletionMethod>;
  PublicMethods : List<ICompletionMethod> {
    get {
        // generate filtered list if needed
       _CachedMethodList;
    }
  }
}

So it can seem trivial but it is how I see the thing.




More information about the devel-en mailing list