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

[Lluis Sanchez Gual]

See comments inline.

El ds 26 de 09 de 2009 a les 14:57 +0200, en/na Mike Krüger va escriure:
> Hi
> 
> 
> > The current situation is that if a non .NET language wants to provide
> > support for 1), we are forcing the use of the MD DOM, even when it
> > really doesn't fit. And there isn't much gain with that, because that
> > language won't be really able to leverage 2) and 3). The type
> > resolution
> > rules of the MD DOM strictly follow the .NET semantics, so it won't be
> > of much use for non .NET languages. Also, as a general purpose DOM for
> > the language it won't be really useful because it won't allow
> > expressing
> > the particularities of the language.
> > 
> 
> Type resolution isn't done in the MD DOM most resolving is done by the
> backends. 

I know most of the work is done by the backends, but still the parser
service does .NET specific resolution work which is useless to other
languages. See ProjectDom.SearchType for example.

> Our DOM it can be a bit better at genericity than the current one. But
> we won't never get a 'general purpose' dom. It should just describe the
> most basic language structures we likely encounter.
> 
> > My ideas for improving the situation are the following:
> > 
> >       * Create a new DOM, which would be very high level, with just
> > the
> >         information required to support 1). It would be a simple DOM,
> >         intended only for displaying information to the user, not for
> >         type resolution or other operations.
> 
> I don't think a new DOM is required the current one represents the .NET
> reflection API and that's a good sharing point across all .NET
> languages.

That's OK for .NET languages, but we are talking about improving support
for non-.NET languages.

> I would change the current one a bit so that it's more mighty
> than the reflection API. Some languages that are a bit different can be
> wrapped to .NET classes by their compiler and it would be nice if we can
> support those languages.
> 
> Type resolution is done in the language backends. It does have some
> operations but these are common accross all languages that use .NET
> (like give all types in a namespace). When building a non .NET binding
> there is no need to use these .NET specific features. 

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.

My idea of new DOM is to create a set of interfaces which can be
implemented by non-.net language DOMs. Those interfaces would provide
just the enough information that usually has to be shown to the user.
They would be very generic, and could have a tree-like structure like
the one you are proposing. But the main idea is that those interfaces
are not meant to be used as part of any resolution process, or
refactoring, or any other operation that requires rich information about
the types. We already have language-specific DOMs to do that. Instead,
these would be used only for displaying information to the user.

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

> 
> My suggestion for making the DOM more general:
> Doing anything with a tree node as base and have some types of tree
> nodes (file/namespace/class/method etc). All tree nodes have:
> 
> * Link to their parent
> * Know their childrin
> * Have connections to their siblings
> 
> Accessing the children/parents is the same for all these DOM nodes. Some
> operations on the current DOM have become a bit too difficult and they
> would be easier with a general tree as underlying data structure.
> 
> It has limits to build a general DOM - I would draw the line
> between .NET/non .NET language. The output done by the ambiences limits
> a bit the flexibility of the DOM. But I think that ambiences are a good
> idea.
> 
> Some examples .NET specific things that we use but will clash with
> non .NET languages and there isn't anything we can do about:
> 
> * Method paramater modifiers out/ref/params - no 'per name' modifier
> * General modifiers (public/protected etc.) - no c++ 'inline' modifier
> or others
> * Just file -> namespace -> type -> member model - no 'pascal units' or
> declaration/implementation models (#include) or any other form of
> representation
> * Just the .NET constructs (no 'typedef' for example).
> 
> ... and maybe more
> 
> Things we currently support but .NET doesn't:
> 
> * Multiple inheritance
> 
> Things we can support with some DOM refactorings but currently we don't:
> 
> * file -> member models (would useful for the c# language too)
> * method -> method will be allowed (local methods are supported by some
> languages)
> * Other constructs ('typedef') which can be supported in a language
> specific ambience. This is a strong point theoretical it would be
> possible that a language brings their own tree.
> 
> ----
> Other operations: 
> If we want to have central support for code completion through a code
> completion database the DOM needs support for some operations. 
> 
> The problem with these operations is now to determine if an operation
> is:
> 
> * Language specific
> * .NET centric
> * General. 
> 
> I don't think that .NET centric operations like IsMemberAcessible or the
> ResolveResults shouldn't be inside the central dom, because it can be re
> used accross some .NET language bindings and if we can make the life
> easier for .NET language bindings - why not. Other languages (if they
> fit in our DOM model) don't need to call/use these features.

If we can generalize a bit the DOM, so some non-.NET languages can reuse
it, that's OK to me. But reusing the full DOM (with all its features and
constraints) should be optional.


> >       * Each .NET language would implement its own DOM to support code
> >         completion.
> 
> It's already required, otherwise resolving won't work - there is no way
> around it. But retieving the .NET code completion information should
> work with our general DOM - otherwise it won't give any access to our
> code completion database. (But language bindings can bring their own
> code completion infrastructure if they want)

All that is OK to me.

> 
> >       * Generalize a bit the parser service, so we can share some of
> > its
> >         logic. We can keep the parser database as it is right now, but
> >         it would be used only for .NET languages. Non .NET languages
> >         would use its own DOM storage model. Maybe we wouldn't be able
> >         to share much, but at least we could share the thread that
> >         checks for changes and triggers parse operations or something
> >         like that.
> > 
> 
> I wouldn't give access for custom (binary)database plugins, because the
> database exposes a model and other languages that don't fit into the
> model won't share the same logic/models. Our database uses a custom
> binary format and some tables to speed up some operations.

That's not what I'm proposing.

> 
> I would just add support for binary serialization of custom DOM nodes. 
> 
> Bringing other models into our 'database' (which isn't a real database)
> would require that they write their own data storage and logic/models
> and not interfere with the current binary format (depending on what the
> plugins want to do). I think if they don't support our DOM model they
> should bring their own 'database' implementation. 

And that's just what I'm proposing. Notice that I talked about
generalizing the parser *service*, not the parser *database*. The parser
service is in charge of driving the parse operations of project files
and referenced assemblies. It can be generalized a bit to allow plugging
other parsing systems on it, with their own database systems.

> Another point is that
> the database is accessible only through DOM models - that'll make it
> even more unlikely that a language can put some plugin into it.
> 
> Therefore I don't see a good reason for this (But this will depend on
> the user requests - I think some work can be done by the language
> implementors).
> 
> btw. how about switching to SQLite for the parser database ?

If a SQLite based database provides equal or faster access times, with a
reasonable memory use, we can consider it.

Lluis.