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

[Mike Krüger]

Hi

> > + Remove compilation unit, replace it with IFile.
> 
> I'm not sure what's the best way to approach this.
> For a lot of languages, file-level separation doesn't make sense: it
> may require the contents of multiple files (whose relationship is not
> explicitly specified at the source level) to build a coherent model
> for any one file (Vala); nodes may be declared and/or defined across
> multiple files (C, C#, Ruby, Python); etc. These issues can be worked
> out / worked around while retaining the IFile model, but IMO they
> /should/ be worked out before any code gets changed.
> 

Doesn't matter at this level, because it's required to get the file
where the node is declared. That is the main reason for using a IFile
node. To define cross file nodes (like partial types in c#) it's
required to do something like the CompoundType. This doesn't change - in
contrast it makes more sense, because now CompoundType has a compilation
unit attached which is really senseless for this type.

> > 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.
> 
> It would be nice to have a more "global" (per-solution? per-project?)
> builtin parse db that's a sink for any/all parse operations, and _the_
> source for completion, quickfinder, folding, class browser,
> refactoring, etc.
> 

We've a 'builtin' parse db where all parse operations 'should' occur -
this is the source for completion, class browser, folding markers and
quick finder.

The problem is refactoring and folding. Folding can be partially done
for all languages but refactoring (and the resolving for completion) is
language bound. I've tried to merge at least c#/vb.net in the past but I
doubt that this did really make sense - at least there are always nodes
or properties that are incompatible with language X. This makes the DOM
harder to handle and visitors or analyzers harder to write/maintain.

But what can be done is dom node sharing - having the language bound dom
using the monodevelop dom structures, wrapping the monodevelop
interfaces (this will safe one tree conversion). But at the end the DOMs
are still distinct. But I would like to have more shared data structures
(for example having always translate the coordinates NRefactor location
<-> DOM location <-> DocumentLocation <-> text offsets can drive me
crazy, as well as IReturnType <-> TypeReference).

I think that language bindings need to bring their own dom for
refactoring, resolving and code formatting. These things are strictly
bound to the language and can't be abstracted - except for having two
very similiar languages (but even than it has a price).
But the good thing is that much other stuff can be shared - that's what
the monodevlop DOM is for. 

But there should be a central point where the language specific DOM
should be available (I think the Document is the right place).

Regards
Mike