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

[Mike Krüger]

Hi

> I feel there is some misunderstanding here. If we introduce a new set of
> INew* interfaces we'll certainly have to track the changes in
> MethodNodeBuilder and all the builders. And those changes will include
> rendering child nodes, since any node can have child nodes.
> 

Don't solve the case, where the DOM goes deeper than methods. I'm sure
you're coming up with an interface: IClassBrowserProvider { bool
IncludeInClassBrowser { get; }} that 'just' needs to be provided for
every dom. 
The class browser works better when non .NET languages don't re-use our
DOM, if they use their own one they can add their node builders to the
class browser and the thing works.

> > 
> > 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.
> 
> This has a very simple solution:
> 
> interface IQuickMemberNavigationProvider
> {
> 	IEnumerable<INode> GetTypes ();
> 	IEnumerable<INode> GetMembers (INode type);
> }
> 
> to be implemented by language bindings.
> 

Doesn't solve the issue with more than one panel or three panels. You
need something like:
interface IQuickMemberNavigationProvider
{
	IEnumerable<IQuickNavigationPanel> GetPanels ();
}
-> then the quick navigation code has nothing to do with any dom. 

> > 
> > 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.
> 
> I showed it some posts ago:
> 
> class DomField: IMember, INewField
> {
>         public string GetDescription (SomeContext ctx)
>         {
>                 return ctx.Ambience.GetString (this, ctx.AmbienceOptions);
>         }
>         ...
> }

Doesn't solve what I'm describing, because it doesn't solve the problem
for the reflection source. Or you're saying that we use a same set of
classes for every .NET language - that is what we currently have. 

You're coming up with a design that isn't better than the thing we
already have, it's just the same. The discussion is about visitors vs.
member methods - this is pointless.

> I think we have to look at this case by case. For the tooltip case,
> maybe this is enough:
> 
> interface ITooltipProvider
> {
> 	string GetMarkup (INode node);
> }
> 
> to be implemented in every non-.net language binding.
> 

Just another DOM extender interface - you see the design gets more and
more complicated this way ? It's generally not possible to handle every
possible language output/model in a single GetString() - you'll get
scaling problems. If you try this you basically come up with:

INode { 
	GetDescription (CaseEnum, SomeContext ctx); 
}

CaseEnum { CompletionList, CompletionListTooltip, ParameterTooltip,
ParameterDescription, ClassBrowser, QuickNavigationList, ... }

SomeContext { ... } 
ClassBrowserContext : SomeContext { ... }
CompletionContext : SomeContext { ... }
ParameterListContext : SomeContext { ... } 
..

Is that really an option ? What are the others saying ? (The problem
will be adding new controls that display DOM stuff - currently we've a
set of display options where the controls choose from).

> > 
> > 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).
> 
> No, what I'm proposing does not involve implementing additional
> widgets/infrastructure. See above.
> 

But to change every widget/infrastructure with an interface that may not
work for the case the language implementor needs, doesn't add
functionality and makes the life more difficult implementing standard
language bindings isn't a solution.

Again what I wanted:

Extend the MD DOM to make it EASIER to implement .NET based languages -
and MAYBE being able to map non .NET languages to it. I don't intend to 
make anything HARDER to implement for .NET languages.

What I learned from our discussion:

a) Don't provide too much infrastructure for trees you don't yet know
how they look like.
b) Make every component of monodevelop extendable without sticking to a
specific DOM - provide defaults for the .NET based DOM.

Reagds
Mike