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

[Lluis Sanchez Gual]

El dl 28 de 09 de 2009 a les 19:27 +0200, en/na Mike Krüger va escriure:
> Hi
> 
> > "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*.
> >
> 
> Ok and in the end we would've a .NET infrastructure that works with .NET
> classes and a 'do it on your own' infrastructure. 

To some extent, yes. See the PyBinding case. It has its own
infrastructure for parsing, storing and querying parse information,
resolving and generating completion data. It doesn't need the .NET
infrastructure, which doesn't really fit.

> 
> If you say that the document outline/class pad/go to member dialog/quick
> member navigation can work with the INewField etc. interfaces it's
> simply wrong, because they're the ones that already define/use a .NET
> specfic system.

Why is it specific to .NET? I'm missing something here. The document
outline shows a hierarchy of items. It is so generic that it even works
for XML documents. The class pad is also just a hierarchy of items (for
the whole project in this case). The goto type dialog shows a list of
types in the solution. 

The quick member navigation shows types in the first combo, and members
of the types in the second one. It can easily be redefined to showing
'first level items of the file' in the first combo, and 'children of the
active first level item' in the second combo. Or something like that.

I don't see anything .NET specific in all this.

> 
> Why do you think that there are always types and members, methods,
> fields etc. - in fact every component of monodevelop would need a custom
> entry point where a filler class can fill the contents. Builds
> tree/context menu for the class browser, does add 'columns' to the quick
> navigation pane etc. - at the end almost any component that shows the
> DOM needs to be rewritten/extended to make it work. I don't know if
> anyone will do such a deep integration.

That's the point of the INew* set of interfaces. The MD components will
extract the required information from those interfaces, so no deep
integration will be required.

> 
> What you're proposing above can already be done now, by adding a c+
> ambience that handles a c++ tree extending the current one.
> 
> class CppAmbience : Ambience
> {
> 	public override string GetString (IField field, flags)
> 	{
> 		CppField cppfield = (CppField)field;
> 		return cppfield.Modifiers + " " + cppfield.Type + " " + cppfield.Name;
> 	}
> }
> (yes this ambience won't work on a non c++ tree, but it would be
> possible to fill for example the code completion window or quick class
> browser with c++ objects and a c++ ambience).

Yes, that's currently possible (with some tweaks). But it means that the
language has to implement all the DOM interfaces: IField, IMethod,
IType, etc, which are full of .NET specific stuff. Yes, you can just
throw NotSupportedException of all .NET specific methods and properties,
but that's just unnecessary bloat. If anything, it would be better to
have:

class CppAmbience : Ambience
{
	public override string GetString (INode field, flags)
	{
		CppField cppfield = field as CppField;
		if (cppfield != null)
			return cppfield.Modifiers + " " + cppfield.Type + " " + cppfield.Name;
		...
	}
}

That would work, although I don't see the benefit of separating data
from display data in non .NET languages, since there will be a 1 to 1
correspondence between data and display data.

Lluis.