[Monodevelop-devel] Working on the monodevelop dom after 2.2
Christian Hergert
christian.hergert at gmail.com
Mon Sep 28 09:34:58 EDT 2009
Having done a SQLite database for PyBinding, my primary concern is migration
of schemas and upgrading on the fly. It's largely a PITA (however perhaps
the ParserDatabase is as well).
-- Christian
On Mon, Sep 28, 2009 at 4:47 AM, Lluis Sanchez Gual <lluis at novell.com>wrote:
> See comments inline.
>
> El ds 26 de 09 de 2009 a les 14:57 +0200, en/na Mike Krüger va escriure:
> > Hi
> >
> >
> > > 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.
> > >
> >
> > Type resolution isn't done in the MD DOM most resolving is done by the
> > backends.
>
> I know most of the work is done by the backends, but still the parser
> service does .NET specific resolution work which is useless to other
> languages. See ProjectDom.SearchType for example.
>
> > Our DOM it can be a bit better at genericity than the current one. But
> > we won't never get a 'general purpose' dom. It should just describe the
> > most basic language structures we likely encounter.
> >
> > > 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.
> >
> > I don't think a new DOM is required the current one represents the .NET
> > reflection API and that's a good sharing point across all .NET
> > languages.
>
> That's OK for .NET languages, but we are talking about improving support
> for non-.NET languages.
>
> > I would change the current one a bit so that it's more mighty
> > than the reflection API. Some languages that are a bit different can be
> > wrapped to .NET classes by their compiler and it would be nice if we can
> > support those languages.
> >
> > Type resolution is done in the language backends. It does have some
> > operations but these are common accross all languages that use .NET
> > (like give all types in a namespace). When building a non .NET binding
> > there is no need to use these .NET specific features.
>
> Also, there is no need to be unnecessarily constrained by them. For
> example, to show the current method in the members combo box, the
> following interface would be enough:
>
> interface INewMethod
> {
> string GetDescription (SomeContext ctx);
> string Icon { get; }
> Region BodyRegion { get; }
> }
>
> That would be very easy to implement by a non .net language, and it is
> not constraining the implementation in any way. The current IMethod
> interface constraints the implementation to use a specific set of
> modifiers, implement stuff like TypeParameters which won't be used, and
> force the use of a parameters collection which also have .net specific
> modifiers. And all this for just being able to build a string describing
> a method.
>
> My idea of new DOM is to create a set of interfaces which can be
> implemented by non-.net language DOMs. Those interfaces would provide
> just the enough information that usually has to be shown to the user.
> They would be very generic, and could have a tree-like structure like
> the one you are proposing. But the main idea is that those interfaces
> are not meant to be used as part of any resolution process, or
> refactoring, or any other operation that requires rich information about
> the types. We already have language-specific DOMs to do that. Instead,
> these would be used only for displaying information to the user.
>
> The current DOM would also implement those interfaces, so .NET languages
> (for which the current DOM works great) wouldn't need to implement them.
>
> >
> > My suggestion for making the DOM more general:
> > Doing anything with a tree node as base and have some types of tree
> > nodes (file/namespace/class/method etc). All tree nodes have:
> >
> > * Link to their parent
> > * Know their childrin
> > * Have connections to their siblings
> >
> > Accessing the children/parents is the same for all these DOM nodes. Some
> > operations on the current DOM have become a bit too difficult and they
> > would be easier with a general tree as underlying data structure.
> >
> > It has limits to build a general DOM - I would draw the line
> > between .NET/non .NET language. The output done by the ambiences limits
> > a bit the flexibility of the DOM. But I think that ambiences are a good
> > idea.
> >
> > Some examples .NET specific things that we use but will clash with
> > non .NET languages and there isn't anything we can do about:
> >
> > * Method paramater modifiers out/ref/params - no 'per name' modifier
> > * General modifiers (public/protected etc.) - no c++ 'inline' modifier
> > or others
> > * Just file -> namespace -> type -> member model - no 'pascal units' or
> > declaration/implementation models (#include) or any other form of
> > representation
> > * Just the .NET constructs (no 'typedef' for example).
> >
> > ... and maybe more
> >
> > Things we currently support but .NET doesn't:
> >
> > * Multiple inheritance
> >
> > Things we can support with some DOM refactorings but currently we don't:
> >
> > * file -> member models (would useful for the c# language too)
> > * method -> method will be allowed (local methods are supported by some
> > languages)
> > * Other constructs ('typedef') which can be supported in a language
> > specific ambience. This is a strong point theoretical it would be
> > possible that a language brings their own tree.
> >
> > ----
> > Other operations:
> > If we want to have central support for code completion through a code
> > completion database the DOM needs support for some operations.
> >
> > The problem with these operations is now to determine if an operation
> > is:
> >
> > * Language specific
> > * .NET centric
> > * General.
> >
> > I don't think that .NET centric operations like IsMemberAcessible or the
> > ResolveResults shouldn't be inside the central dom, because it can be re
> > used accross some .NET language bindings and if we can make the life
> > easier for .NET language bindings - why not. Other languages (if they
> > fit in our DOM model) don't need to call/use these features.
>
> If we can generalize a bit the DOM, so some non-.NET languages can reuse
> it, that's OK to me. But reusing the full DOM (with all its features and
> constraints) should be optional.
>
>
> > > * Each .NET language would implement its own DOM to support code
> > > completion.
> >
> > It's already required, otherwise resolving won't work - there is no way
> > around it. But retieving the .NET code completion information should
> > work with our general DOM - otherwise it won't give any access to our
> > code completion database. (But language bindings can bring their own
> > code completion infrastructure if they want)
>
> All that is OK to me.
>
> >
> > > * 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.
> > >
> >
> > I wouldn't give access for custom (binary)database plugins, because the
> > database exposes a model and other languages that don't fit into the
> > model won't share the same logic/models. Our database uses a custom
> > binary format and some tables to speed up some operations.
>
> That's not what I'm proposing.
>
> >
> > I would just add support for binary serialization of custom DOM nodes.
> >
> > Bringing other models into our 'database' (which isn't a real database)
> > would require that they write their own data storage and logic/models
> > and not interfere with the current binary format (depending on what the
> > plugins want to do). I think if they don't support our DOM model they
> > should bring their own 'database' implementation.
>
> And that's just what I'm proposing. Notice that I talked about
> generalizing the parser *service*, not the parser *database*. The parser
> service is in charge of driving the parse operations of project files
> and referenced assemblies. It can be generalized a bit to allow plugging
> other parsing systems on it, with their own database systems.
>
> > Another point is that
> > the database is accessible only through DOM models - that'll make it
> > even more unlikely that a language can put some plugin into it.
> >
> > Therefore I don't see a good reason for this (But this will depend on
> > the user requests - I think some work can be done by the language
> > implementors).
> >
> > btw. how about switching to SQLite for the parser database ?
>
> If a SQLite based database provides equal or faster access times, with a
> reasonable memory use, we can consider it.
>
> Lluis.
>
>
> _______________________________________________
> Monodevelop-devel-list mailing list
> Monodevelop-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/monodevelop-devel-list/attachments/20090928/a2eee449/attachment-0001.html
More information about the Monodevelop-devel-list
mailing list