[MonoDevelop] PATCH: More detailed generic paramters for code completion

[Lluis Sanchez]

Hi!

> Attached is a proposal of how to store information about generic 
> parameters. Generic arguments should simply be
> 
> Please, take a look at the attached files, and comment on them (have I 
> missed the point?).

It looks much better now. Just a couple of comments:

      * I'm concerned about using generic collections in the public api,
        since languages which don't support them (does boo have
        generics?) won't be able to extend it. Maybe using concrete
        types like this would be enough?:
        public class TypeConstraintList: List<TypeConstraint> {}

      * Wouldn't TypeConstraint just be an IReturnType (after adding a
        GenericArguments collection to it)? The same for
        GenericArgument.

      * Do we need a special handling for naked type constraints? I
        think we can easily find the declaration of the original generic
        type.

> 
> And another thing: It is said that MonoDevelop copied a lot from 
> SharpDevelop. It was suggested by Gryegory to port whatever they have in 
> SharpDevelop to MonoDevelop.
> 
> I'm just interested in what your plans for code assistance were (before 
> I happened)? As I said, I'm willing to create a plan for code assistance 
> in MonoDevelop (be it with or without the help of code from SharpDevelop).

The plan was to wait for somebody interested in working on it. And the
plan seems to work so far ;-)

Reusing code from SharpDevelop is a good thing, as long as it fits in
MonoDevelop. MD's code completion implementation is derived from
SharpDevelop's, for the good and the bad. One of the changes we did was
to make it independent from the text editor, so we can use
code-completion in other contexts (for example, it is being used in the
boo shell). SD's implementation is still tied to the editor, so at least
we have now one more layer of independence. If there are pieces of SD
code which can be integrated in MD without losing the extra features we
have (if there are), then go ahead.

Lluis.