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

[Mike Krüger]

Hi

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

Ok I've looked a bit at the source code.

Class pad:

ClassNodeBuilder, FieldNodeBuilder, MethodNodeBuilder,
NamespaceNodeBuilder etc. 

But it can be extended using the addin tree - but the things we have are
very specific. For example: I've took a look at the MethodNodeBuilder -
it doesn't build child nodes (yes there are languages with methods in
methods). Taking this example it wouldn't even work if we had a new
INewMethod interface for such a language to be build with the class pad,
because the MethodNodeBuilder that takes care of building these objects
would prevent building child nodes.

Quick Member navigation - it's not so easy to set the rules:

'showing first level items of the file' means:
+ Showing only the namespaces -> no containing types (they're first
level, and will be part of the DOM as nodes)
+ Don't show inner types (they're second level at best)

'children of the active first level item' means:
+ Show the current inner type (should be in the type selector).
+ Show the current statement, if the DOM is extended and more specific
than the monodevelop DOM.

Then there are 3 navigators: types/members/regions. That doesn't make
sense for some cases (think of C, there are no members/regions). 

Document outline:
The document outline that shows the hierarchy requires that
IOutlinedDocument is implemented. A XML and MD DOM get different
implementations of this interface. It's very general:

public interface IOutlinedDocument
{
	Gtk.Widget GetOutlineWidget ();
	void ReleaseOutlineWidget ();
}

I would say that's one of the best components we have for extensibility.
Because it doesn't 'lock' into a specific model. The downside is that it
doesn't provide much to re-use. But I think we should have this sort of
extensibility for all components and let the non-.NET languages a way to
work around all pre defined structures and replace the components with
an own way. This ensures that we can't make a mistake.

btw. another thing: All pads/output function currently build on ambience
flags - but for other languages there may be different sets of flags
required for displaying the information at that point. 

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

We've classes that implement the interfaces, no .NET specific
implementation is required. But the other thing is that a new languages
now would ALWAYS require to implement all DOM interfaces that are full
of .NET specific stuff. (ok could use the same base class)
You've still not told how to display a VB output, Boo output and c#
output of a reflection source when putting the output code inside the
DOM objects. I think that's not easily possible.

MD side:
Code Completion DB -> Data (in which DOM format)

Language binding:
Own Dom info + wants to display code completion data from the code
completion db 

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

The benefit is that the non .NET languages can communicate with
MonoDevelop components to produce output. And that the .NET unspecific
types/members etc. could be implemented today.
Sometimes the output is altered (adding markup to names etc.) by
consuming code. Outputting the text from the DOM isn't very easy and
just a GetString () doesn't cut the edge. We've to display this
information in various tooltips/lists with different options (short name
vs. long name). Therefore the GetString () needs to get the same
parameters as ambiences.

I tend to make the monodevelop DOM stuff .NET dependent in the type
model, generalize the object model so that other .NET languages can be
supported that are more far from C#/VB.NET and have a way to do
something like the IOutlinedDocument for each component. I don't want to
make the life harder for .NET language implementors when the non .NET
language implementors get little to no gain (See above - they need to
implement their own widgets/infrastructure - regardless of what we try,
more worse they can run into dead ends when trying to re-use the
monodevelop DOM - see the class output pad method example).

Regards
Mike