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

[Mike Krüger]

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. 

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 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.

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).

I will think about it a bit more when I look/work at the source code.
btw. we could need input for people doing a language binding here :)

Mike