Well, I would probably stay just with compiler internal structures or
add most of the code for reading them into CompletionEngine.
GlobalEnv, TypeInfo, TyVar have really most of the needed methods to
gather all completion engine needs.
And well, those structures are public API and cannot be "accidentely"
corrupted (at least not very easily). The only thing I would fear are
the breaking API changes we sometimes do.
So my suggestions are to eliminate wrappers at all and always rely on
the data gathered by compiler itself inside NamespaceTree and
GlobalEnv. Then we should make sure that when the completion event
occurs inside the method, then the types hierarchy is not touched at
all, but simply the method Typer is executed in completion mode.
2006/5/31, Alejandro Serrano <trupill@xxxxxxxx>:
Kamil Skalski escribió:
>>
>> 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.
>
I also can't remember very well the reason the wrappers were started,
but I think it was because the Engine had the objective of being easily
usable from C#, and I saw there were lists, Hashtables, which in that
moment couldn't be used in C# very well. I've checked that, yes, that's
one of the points that slow down the Engine, so I've thought about
delaying the return of information in the wrappers until the information
is really needed.
I'll try to do it during the weekend, but I would like to know what do
you think about it, and which other points should I take on account when
changing them. However, I still think that returning the plain compiler
internal interfaces is not the best idea, because it may alter some
internal structure.
Alejandro Serrano
______________________________________________
LLama Gratis a cualquier PC del Mundo.
Llamadas a fijos y m�viles desde 1 c�ntimo por minuto.
http://es.voice.yahoo.com
_______________________________________________
https://nemerle.org/mailman/listinfo/devel-en
--
Kamil Skalski
http://nazgul.omega.pl
| 