[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