[nem-en] Completion thoughts

[Alejandro Serrano]

NoiseEHC escribió:
> 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)
I think the important step here is to have most of the shared code in 
ManagerClass. However, I don't find it a real issue, as the engine is 
using the compiler methods, it just runs on a "special mode". But 
lexing, parsing and typing are shared by both. That's one of the reasons 
that makes neccessary for the engine to live inside Nemerle.Compiler.dll.
> 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.
Well, I think those interfaces already exist. In ClassMembers.n (if my 
memory does not fail), there is IMember, IMethod, IProperty and so on 
(I'm feeling more and more embarrassed while writing asking myself why I 
created those wrappers... :-( ). Those interfaces provide information 
for both types and members from external assemblies and source code in a 
very powerful way. In that way, changing of the Nemerle compiler 
codebase should not break the engine.
I don't think there's a real need of developing two versions of the same 
compiler. Compilation is not slowed down too much, and user will be 
allowed to update their Nemerle compilers without worrying about whether 
the version has or not completion. In my opinion, that would just divide 
the actual package in two.

		
______________________________________________ 
LLama Gratis a cualquier PC del Mundo. 
Llamadas a fijos y móviles desde 1 céntimo por minuto. 
http://es.voice.yahoo.com