[Monodevelop-devel] Working on the monodevelop dom after 2.2
Levi Bard
taktaktaktaktaktaktaktaktaktak at gmail.com
Wed Sep 23 11:14:41 EDT 2009
> + Replace IDomVisitable with a tree node - each tree node knows it's
> parent, children and siblings.
I'm fine with that.
> + 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.
> 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.
> And I would like to replace the DomLocation with DocumentLocation from
> the text editor (or offset based from the text editor) - currently we've
> too many ways of representing a location in a file.
Works for me - I keep having to manually offset my DomLocation values
in order for folds and things to show up at the right spots.
--
http://homes.eff.org/~barlow/EconomyOfIdeas.html
http://www.dreamsongs.com/MobSoftware.html
http://www.gnu.org/philosophy/shouldbefree.html
More information about the Monodevelop-devel-list
mailing list