[Monodevelop-devel] Working on the monodevelop dom after 2.2

[Mike Krüger]

Hi

> That's OK for .NET languages, but we are talking about improving support
> for non-.NET languages.
> 

For the DOM - no not really. I don't think that we can support non .NET
languages at the level we're supporting .NET languages. My goal would be
to improve .NET languages that don't fit into the C# model (like pascal
for example) and maybe improving the ability for plugging in non .NET
languages. 

What are the language binding implementors saying on this ?

> Also, there is no need to be unnecessarily constrained by them. For
> example, to show the current method in the members combo box, the
> following interface would be enough:
> 
> interface INewMethod
> {
> 	string GetDescription (SomeContext ctx);
> 	string Icon { get; }
> 	Region BodyRegion { get; }
> }
>
> 
> That would be very easy to implement by a non .net language, and it is
> not constraining the implementation in any way. The current IMethod
> interface constraints the implementation to use a specific set of
> modifiers, implement stuff like TypeParameters which won't be used, and
> force the use of a parameters collection which also have .net specific
> modifiers. And all this for just being able to build a string describing
> a method.
> 

Ok then each .NET language vb/c#/boo etc. needs an own INewMethod
implementation (and full monodevelop dom). To make it more worse to
which tree should we convert the assemblies to ? Then each specific
language needs to be able to convert cecil to their dom. (otherwise we
won't get descriptions for the reflection objects). And to make it even
more worse a solution that contains different .NET languages needs to
share their DOMs as well. It would be very strange if vb.net syntax
would pop up in a c# project that uses something from a vb.net project.

> My idea of new DOM is to create a set of interfaces which can be
> implemented by non-.net language DOMs. Those interfaces would provide
> just the enough information that usually has to be shown to the user.
> They would be very generic, and could have a tree-like structure like
> the one you are proposing. But the main idea is that those interfaces
> are not meant to be used as part of any resolution process, or
> refactoring, or any other operation that requires rich information about
> the types. We already have language-specific DOMs to do that. Instead,
> these would be used only for displaying information to the user.
> 

The user wants to display modifiers and stuff that is in ambience, some
languages have: type varName others tend to use varName : type.
Currently I separated the display from the data (ambiences) therefore
it's possible to have the language specfic display everywhere (even from
reflection generated data).
With the change above we're going a step back, because we make it more
difficult for .NET languages - for almost no gain. Theoretically each
component that displays some other sort of a language may need changes,
if a language is really, really far away of c#. At the end we're going
to let each language binding bring their own class browser, code
completion, code completion db, quick navigator etc. only having the
text editor/project system in common.

Regards
Mike