[nem-en] Completion thoughts

[Kamil Skalski]

>
> First of all, I don't like the way the Completion Engine has ended up
> (even though I've developed most of it). The best example is the
> RunCompletionEngine method. This method returns a list of every member
> that may be available into the context, and it translates them from the
> compiler representation to another representation. That seems fine, but
> when I integrated it into MD, I needed to wrap it again, making it a bit
> slow. My opinion is that we should stop returning every member and just
> return information about the context. For use in MD, that would be enough:

I'm not sure why didn't you want to just return compiler's internal
interfaces, like TypeInfo, IMember, IMethod, etc. They already have
most methods you would need for filtering and
obtaining full information about them.
As you said, we should have a good way to obtain the type of given
expression in program, but I think it should be returned directly as
compiler API uses it. Then in any specific IDE integration it can be
analysed and also compiler can be asked to provide any additional
information. If compiler's interfaces lack some properties or methods,
like IsVolatile, etc. we should add it there, not create artificial
wrappers.

> - The members the object is allowed to call because of it context. For
> that, "AllowPrivate", "AllowInternal", "AllowProtected" would suffice.
> - The extension classes that have member that would fit for the object.
> With the latest three datas, an IDE will have enough information to show
> the completion window.

Such things can be easily filtered when we operate on compiler's structures.

>
> MD doesn't allow to colorize files dinamically (as far as I know), but
> for VSIP integration, I've read that a good interface to the lexer,
> including SaveState and RestoreState methods would be fine. Maybe, for

Problem with Save / RestoreState is that there is no clear sign when
we can cleanup this storage. There are several fields, which must be
saved in lexer:
- line and column number
- preparser stack state
- indentation syntax fields


>
> - Each engine should have its own state (which its mostly done, maybe
> remove the neccessity of Manager.Instance)

The Manager should now completely contain its state. I didn't try to
run two instances yet, but it should work.
Manager.Instance is here to stay as there are many places where we
cannot easily access current ManageClass object. But this should be
not a problem, if it will be assigned with current manager object on
every operation performed on Manager. We will also mark it with a
special attribute, which makes this static field unique in every
thread, so it should be even possible to run two Managers in parallel.


> - Add / remove references on the fly

I think this requires rebuilding of any cached information in
compiler, as changing referenced assemblies can invalidate any
information used by compiler. But this is not bad, since usually
references are not changed often.

> - Add / remove / replace code files, making the neccessary changes in
> the tree (that means, if I've updated one file with changes on some
> interface, alter the classes that implement it as needed). The only
> problem that I see are partial classes.

Also classes subtyping changed one. But in general it is now possible
to just remove the program nodes and leave all information about
external types intact. This is how Options.PersistentLibraries work.
I will try to enable it in CompletionEngine.

> - I would remove the information about Defines, as IDEs usually don't
> use it to colorize

Standard Lexer uses it, so I don't see the point in removing it just
for completion engine.

> - Get the actual type tree in any moment, wrapping it in some way
> information is not retrieved until needed. That tree would be made of
> "Class" object with "Members" objects. Each member of the "Method" type
> would have an additional method: "PerformCompletion" that would take the
> string to complete and return the type of it as discussed above.

I see it in form of extending compiler's API or just adding utility
methods in CompletionEngine, which would make such things easier, but
still operate on compiler's structures.

And thanks a lot for working on it! :-)

-- 
Kamil Skalski
http://nazgul.omega.pl