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

[Mike Krüger]

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

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.

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

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

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

Regards
Mike