[MonoDevelop] Parser and code completion

[Alejandro Serrano]

Lluis Sanchez escribió:
>> Firstly:
>>         It seems to me that fixing the 'Parser' part will not be a big
>>         problem. The following code should be added:
>>         in IClass:
>>         StringCollection GenericParameters {
>>             get;
>>         }
>>     
>
> What about type constraints? We should also have this information.
>   
>   
>>         
>>         in IMethod:
>>         StringCollection GenericParameters {
>>             get;
>>         }
>>         
>>         in IReturnType:
>>         StringCollection GenericArguments {
>>             get;
>>         }
>>     
>
> Shouldn't this return a collection of IReturnType?
>
>   
>>         
>>         in IParameter:
>>         StringCollection GenericArguments {
>>             get;
>>         }
>>     
>
> I'm also wondering if IClass.BaseTypes should now be a list of
> IReturnType instead of a list of String, since base types can now have
> generic arguments.
>   
My opinion is that ReturnType should continue having just a string, 
instead of generic arguments. That is because, when you have:

class Example<T>
{
    public T AGenericMethod () { ... }
}

You still need to save the ReturnType as the string "T".
So, or we rework everything to work as in Reflection (IClass has a 
IsGenericArgument property, ReturnType has a class instead of a string, 
GenericParameters is a list of types with IsGenericArgument == true...) 
or we just use a string in ReturnType (I'm using it in Nemerle binding 
and I've found it enough).
Using a Reflection-like system would be better because it allows 
constraints, and open and closed generic types are done the same way.
>   
>> ...
>>     
>
> Yes, changes in the language bindings should be included in the patch to
> avoid breaking the build when it is committed.
>   
The latest patch I sent to the list also included changes to CSharp and 
Nemerle bindings. No other changes are required to compile as 
GenericParameters is implemented in AbstractClass and AbstractMethod.
>   
>> Secondly:
>>         I'm not entirely sure yet, but I think that adding support for
>>         the requested code completion features (especially snippets,
>>         keyword completion etc.) will be much more of a problem. For
>>         now it seems to me that I will have to rework a large part of
>>         MonoDevelop.Projects.Gui.Completion. What is your opinion
>>         about that?
>>     
>
> Isn't a custom implementation of ICompletionData or
> ICompletionDataProvider enough for what you want to do?
>   
In the implementation I did for some bindings and completion, I had 
enough with ICompletionData and ICompletionDataProvider, as they have 
IClass and IMethods wrapped on them. What is needed is the use of 
Ambience by CompletionData instead of manually getting the names, but 
that's another item.

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