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

[Levi Bard]

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

This is more or less what non-.NET languages have to do currently:
Munge some stuff into the DOM for 1), custom implementation for 2), 3)
[which is refactoring also, isn't it?] is basically impossible.

I'm on board with a unified, high-level DOM for populating
quickfinder, classpad, etc. [Zeroth bullet]
If this part is generalized enough to support native hierarchy
structures for various languages [currently missing], easily updatable
[currently exists], and easily and flexibly queryable from addin code
[currently missing], completion doesn't necessarily require its own
DOM, just some completion hooks similar to the existing ones. Things
like Goto Definition and Find References could operate at this level
as well.
Similarly, there's no reason that the same overall storage mechanism
couldn't be used for .NET and non-.NET parse databases, as long as
hooks are exposed for specializing the storage process for specific
DOM implementations.

I would LOVE to see enough assumptions neutralized that I could enable
Stetic or hook into existing refactoring operations for a specific,
arbitrary language.

-- 
http://homes.eff.org/~barlow/EconomyOfIdeas.html
http://www.dreamsongs.com/MobSoftware.html
http://www.gnu.org/philosophy/shouldbefree.html