Re: [anjuta-devel] Aggressivity of merging

[Abderrahim Kitouni <a kitouni gmail com>]

Hi Moritz,

                  في ح، 17-06-2012 عند 16:29 +0200 ، كتب Moritz Lüdecke:
> Hello everybody,
>
> Today I tried to merge the calltip code in language-support-vala with 
> the new parser-engine plugin. Each corresponding method do this in a 
> different way. (see 
> https://github.com/ritze/anjuta-clang/commit/814f11c887e63f0a4b9c71eff17649afd8b99e58#L2R401 
> "plugins/language-support-vala/provider.vala" and 
> "plugins/parser-engine/plugin.c")

FWIW, the vala plugin isn't using IAnjutaSymbol, but is using ValaSymbol
(from libvala) directly. So merging isn't as straightforward as you
might think.

Regarding your IAnjutaParser interface, I think it's better to name it
something else. AFACT, it isn't supposed to be implemented by individual
parser plugins but rather to be shared among them, so the current name
is misleading.

> For example the vala plugin only displays the parameters of the method 
> without the name of the method and parser-engine plugin, which is used 
> in the cpp-java plugin, also shows the name of the method.

As Johannes said, it is better to be consistent, so we should try to
find the best way and implement it once.

> Additionally I couldn't find out, if the parser-engine plugin will be 
> ever append a "..." string for a parameter with variable number of 
> arguments (like args in the main method).

I think the best way to know is to try it :) start anjuta and try to get
it to show calltips for known varargs functions (like printf or some gtk
functions) and if there are no ..., then it doesn't support it.

> Another point is the cache part, which each language-support plugin 
> does it in a different way too.

My advice is to try and come up with an interface first and try to see
how to implement it best (looking at the existing implementations) and
then try to port existing plugins to the new interface progressively.
For example, I'd like to see what you want a language support plugin to
do when activated (in pseudocode, what would need to be implemented if
we wanted to add a new language).

I'd also like to make sure I understand your diagram, so IIUC, what you
have now is: "completion engine interface" is IAnjutaParser interface
and its implementation in the parser-engine plugin, right? Also, I'm not
sure about how the plugins are supposed to interact

The more I think about this, the more I think it might be a good idea to
use libpeas for plugins, as that would allow for having multiple
"extensions" (libpeas speak for classes implementing a given interface)
in the same plugin, and that would help us with the problem of splitting
plugins.

What do you think of this?

Cheers,
Abderrahim