[Monodevelop-devel] Brainstorming for 2.4 code quality

[Mike Krüger]

Hi

> We should review the api and see how language bindings are currently
> used. So for example, if we move the comment tag properties to syntax
> modes, and parser/refactorer have their own extension points, there
> isn't much left in ILanguageBinding. This code has evolved a lot since
> it was designed, so maybe it can go away or it can be replaced by
> something else.
> 

Ok my suggestion would be removing the language binding and replacing it
with an ICompiler interface (that is the only functionality that is
really used). We then can have the IParser, ICompiler, IResolver
interfaces directly in the addin tree. There is no need that each
language binding provides a wrapper class there.

> > - They provide comment tags, but we get comment tags from the syntax
> > modes.
> 
> I think we should get rid of those comment tag properties from
> ILanguageBinding, and use only the info from syntax modes. However,
> they
> are still being used when creating a new file to insert the license
> header. We have to find a way of querying information from syntax
> modes
> without having and instance of an editor.
> 

Instance of an editor isn't required for accessing the syntax modes. The
syntax mode service is static.

> > - They bind to a 'language' and can ask if a file is a source code
> file
> > ore not - they're not using our newer mime type system
> (inconsistent!)
> 
> The mime-type system doesn't have information about which types are
> source code files. We have per-mime-type formatting policies, but this
> is unrelated.
> 

The language system doesn't have good information too, the language
binding system with the 'language' property was an idea to mimic the
mime type system. Unfortunately binding this to a IProject doesn't work
for example a parser or refactorer for a "C#" language needs to be
different, because the project can contain C# files an ASP.NET files. 
It makes sense to bind a compiler to a project (The ICompiler for
example). This can be done with a project id, but we're using guids for
them the language name is a leftover from old #d days and hasn't any
real meaning.

> > - Maybe they should be attached to a ProjectDom or ViewContent to allow
> > easier access.
> 
> I don't think that's necessary. You can already get a language binding
> from Project, and you can get a project from ProjectDom and ViewContent.
> 
A project can contain different languages (ASP.NET project for example)
therefore binding some functions to the mime type makes more sense. I
think the view content (or 'Document') would be a good point to place
this. For example accessing the 'comment' tags could be handled on the
'Document' level. I think it makes sense to have a ICompiler on the
project level and most of the rest on the mime type/per document level.


> Our resources are limited, so we have to be careful about where we put
> our development effort. We should focus on fixing, improving or
> implementing features that users really need. Improving the API is part
> of the work, but we have to find the right effort/benefit balance.
> 

Improving the API helps us. 

Regards
Mike