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

[Lluis Sanchez Gual]

El dt 22 de 09 de 2009 a les 14:08 +0200, en/na Mike Krüger va escriure:
> Hi
> 
> Currently we've two DOMs: 
> 
> MonoDevelop DOM
> Language specific DOM
> 
> The idea of the monodevelop dom is that most parts of the IDE only use
> the upper level (namespaces/types/members etc.) of the .NET doms for
> some parts (class browser, quick method navigation etc.). This DOM
> reflects the capabilities of .NET reflection.
> 
> Now some people have the opinion that this limits monodevelop when
> supporting non .NET languages and I think they're right.
> I see that currently the main problem is that monodevelop uses the
> type->member model.
> I would rather suggest working with a tree model instead, adding some
> new 'types' to be able to do have a file->member structure.
> 
> I would:
> 
> + Replace IDomVisitable with a tree node - each tree node knows it's
> parent, children and siblings.
> 
> + Remove compilation unit, replace it with IFile. 
> 
> Then it's possible to have file->methods/fields as well as
> file->type->methods/members and the class browser/code navigator can
> show the new 'model' as well. I don't expect huge changes in the current
> code base. The parser database needs to change a bit, but shouldn't
> change much.

Right now the DOM we have is very .NET centric. It is not just a matter
of DOM structure (e.g. assembly->namespace->type->member), but also
about the semantics of the DOM (for example, all types are subclasses of
System.Object). .NET semantics are everywhere in the DOM.

The problem we have is that we are trying to do too many things with a
single DOM. The MD DOM is used basically for three things:

     1. Fill navigation widgets such as the member/type combos at the
        top of the editor, the document outline or the class pad.
     2. Support code completion for .NET languages. It can be used for
        example to resolve types across all referenced assemblies of a
        project, no matter which language were those assemblies written
        on.
     3. A general purpose DOM, used by add-ins to extract information
        about classes and members and do something with them (for
        example, the Stetic designer uses that to detect classes bound
        to a designer).

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.

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.
      * Make it explicit that the current MD DOM is only for .NET
        languages.
      * Each .NET language would implement its own DOM to support code
        completion.
      * 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.

Lluis.