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

[Lluis Sanchez Gual]

El dl 28 de 09 de 2009 a les 17:43 +0200, en/na Mike Krüger va escriure:
> 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). 

No, you got it wrong. From my previous mail:

"The current DOM would also implement those interfaces, so .NET
languages (for which the current DOM works great) wouldn't need to
implement them."

For example (and this is just an incomplete example), DomField could be
implemented like this:

class DomField: IMember, INewField
{
	public string GetDescription (SomeContext ctx)
	{
		return ctx.Ambience.GetString (this, someFlags);
	}
	...
}

C#, VB, boo and all .net languages would keep using the DOM we have
right now, which would implement INewField, so they don't have to be
changed.

On the other hand, the C++ binding could have this implementation:

class CppField: SomeBaseClass, INewField
{
	public string GetDescription (SomeContext ctx)
	{
		return cppModifiers + " " + type + " " + name;
	}
	...
}

The C++ DOM can be arbitrarily complex and can have its own storage
system, but by implementing INewField, the IDE would be able to display
data about it. In this case it is not necessary to separate data from
display data, because the DOM is specific to C++, so it will always use
C++ syntax.

The members combo, the document outline, the class pad, the go-to-member
dialog and the code completion window can all be impemented based on
INew* interfaces which are more simple and have less implementation
constraints. .NET bindings would just feed those GUI components using
the existing DOM, which would implement INew*. Non .NET bindings would
just provide any DOM implementing INew*.

Lluis.