[Monodevelop-devel] Some new DOM guidance

Lluis Sanchez Gual lluis at novell.com
Mon Jul 28 19:54:31 EDT 2008


Let's explicitly set the rule (although I think it is obvious): if
somebody does a big change or refactoring in the MD core, he is
responsible for ensuring that *all* projects in MD (including everything
in extras) can be properly built and work as expected (modulo bugs to be
fixed as soon as possible when arise). You should take into account that
you are not working alone in the project, and that other people have
better thing to do than tracking api breakages.

For a big change such as the project dom change, the correct process
would be this:

      * Create a branch.
      * Do all changes in the branch, removing old code and adding the
        new one.
      * While doing the changes, merge back to the branch the commits
        done by other people in trunk ('svn merge' is very helpful for
      * Fix all projects using the old code, change them to use the new
      * Do the basic tests to ensure that everything is working fine.
      * Announce the availability of the new branch, and open the branch
        for testing, so that other developers can ensure that there are
        no issues with their own projects.
      * Dogfooding: install and use the new MD for at least a couple of
      * At least one day before the merge to trunk, announce the
        upcoming massive change, so people have time to commit pending
      * Resolve the final conflicts caused by last minute commits.
      * Do the merge and announce it.


El dt 29 de 07 de 2008 a les 00:23 +0200, en/na Mike Krüger va escriure:
> Hi
> Ok. I tried to make it easy to convert old dom code over to new dom
> code.
> Basically it's:
> not longer:
> using MonoDevelop.Projects.Parser;
> instead:
> using MonoDevelop.Projects.Dom;
> not longer: IClass instead: IType
> Parser registration (with the addin tree):
> <Extension path = "/MonoDevelop/Ide/DomParser">
> 	<Class class = "MonoDevelop.CSharpBinding.DomParser" />
> </Extension>
> The parser must extend the MonoDevelop.Projects.Dom.Parser.IParser
> interface. I recommend inheriting from
> MonoDevelop.Projects.Dom.Parser.AbstractParser which makes changes in
> the interface more easy.
> Generally I tried to move functions from some services to the objects
> directly. For example - monodoc documentation could be now accessed by
> System.Xml.XmlNode GetMonodocDocumentation (); instead of the
> documentation service. Or the icon could be get by
> string StockIcon { get; } instead of using the IconService. I'll add
> more functions to the dom. The goal is to make it easier to find
> functions and bring back some responsibility to the objects.
> MonoDevelop.Ide.Gui.Document
> now contains:
> public ICompilationUnit CompilationUnit {
> 	get;
> }
> In former versions the document contained only the text contents, now it
> contains the most recent parse information too.
> For the rest - look at:
> MonoDevelop.Projects.Dom.Parser.ProjectDomService 
> There you have functions like:
> IParser GetParserByMime (string mimeType);
> IParser GetParserByFileName (string fileName);
> ICompilationUnit Parse (Project project, 
>                         string fileName, 
>                         string mimeType)
> For projects:
> ProjectDom GetDatabaseProjectDom (Project project);
> The ProjectDom contains the project parser info (was ParserContext  in
> former versions)
> The Projects will contain the ProjectDom as property, but currently I
> had already too many name clashes. After removing the old infrastructure
> I'll do some refactorings to make the access easier. (I could need some
> input here - maybe someone has new ideas what's missing. Like
> the CompilationUnit inside the Document).
> The project dom contains some functions old dom users will find very
> familiar (like GetNamespaceContents, SearchType).
> I've converted much old code - most is done with renaming and switch
> over the usings. If you've more questions feel free to ask.
> Regards
> Mike
> _______________________________________________
> Monodevelop-devel-list mailing list
> Monodevelop-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list

More information about the Monodevelop-devel-list mailing list