On 2016-08-30 06:29 AM, Colomban Wendling wrote:
Le 29/08/2016 à 03:09, Matthew Brush a écrit :
On 2016-08-28 05:47 PM, Matthew Brush wrote:
[...]
To give an idea, the registration function called by plugins might look something like this:
gboolean ftplugin_register_provider(GeanyPlugin*, GeanyFiletypeID, GeanyFiletypeFeature, GCallback, gpointer);[...]
I forgot to mention, it may turn out that in order to provide a feature, there may be a need for multiple callbacks (ex. activate, deactivate, init_styles, prepare_list, whatever). If this ends up being the case, we would need to either pass a table of callbacks here or perhaps a GObject implementing a particular interface or whatever.
Then probably better make the provide a structure like
GeanyAutoCompleteProvider { GeanyFiletypeID filetype; GCallback feature1; ... }
As long as it's uniform across all features (ie. all or none are using structs whether or not they have multiple features), that's pretty much what I had in mind, and is basically how I represented the internal tracking structures in my experimental code I was playing with.
API-wise I find it neater to keep the parameterization in the parameters list and keep any structures like that as simple vtables, but the difference is rather minute (probably whatever would work better for auto-binding generators to read).
In theory I have nothing against GInterface, but I'm not quite sure it's a good idea to start riddling Geany with GObject API where we already have like 2 non-GObject-ish API styles (plugin registration, Proxy registration, signals…)
Not saying GInterface is a presona non-grata, but that IMO it would have to prove very useful over the other solutions to be used. Especially as people are likely to implement these filetype features in C or C++ more than Python, JavaScript or Ruby, so it should be comfortable in C and C++, and you know you don't like GObject boilerplate :)
I personally believe interfaces/abstract-bases to be the most appropriate technical solution (at least from OOP-languages) at our disposal, but I chose to stay away from that mostly to avoid the social/political/emotional ramifications of it on the discussion. Besides, re-implementing a small portion of it isn't that big a deal and doesn't feel so unnatural for C.
Cheers, Matthew Brush