New plugin API

[Ankit Vani]

Hi Richard

On 9 August 2013 19:44, Richard Laager <rlaager at wiktel.com> wrote:
> Is there some compelling advantage to using one integer with all the bit
> shifting for this instead of two integers (major, minor)?

Originally, I had misunderstood the purpose of "abi_version", which is a
GPluginPluginInfo property, and had written the macros for the purpose of
setting this integer.

However, I still believe it is simpler and easier for plugin authors to have to
just specify one property for the required version of purple, "purple_version".
The only other places where we use this version are when displaying plugin
information in the UI, and when determining whether the library meets the
version requirements of the plugin.

> Maybe on load, plugins should be able to return an error message instead
> of just a boolean. For example: a string is an error message and NULL is
> success. Or do it some other way.

Yes, I was planning on doing that. I was thinking a plugin can call
purple_plugin_set_error(plugin, error) for this purpose before returning FALSE.

> On Fri, 2013-08-09 at 17:35 +0530, Ankit Vani wrote:
>> GPlugin refs everything before returning it to us. So basically you
>> would need to do things like:
>>
>> GPluginPluginInfo *info = gplugin_plugin_get_info(plugin);
>>
>> if (!gplugin_plugin_info_get_name()) {
>>     g_object_unref(info);
>>     return FALSE;
>> }
>>
>> g_object_unref(info);
>> return TRUE;
>
> Yes, do things like that. Don't use things after unref()ing them. Even
> if it works now, it's not guaranteed to stay working. And it sets a bad
> example for others that might read that code and copy the pattern
> elsewhere with other types of objects.

Things often get unnecessarily ugly in some places though. I had initially done
things that way only, and in some places in the UIs, such as in long functions
and loops, it is very easy to miss a return or a break without unrefing. And if
code is added in the future, it may be added to use these objects after they
have been unref'd already.

I think it brings in unnecessary hastle for developers, makes the code more
bug-prone and hard to read.

Moreover, if things are to be done this way, I would suggest not making plugins
an exception, and all GObjects in purple should be dealt with this way. It seems
odd if objects of one subsystems are to be dealt differently than others, and
again, careless mistakes can be made. But if all objects are dealt with this
way, things are only going to get uglier and code is going to get longer and
harder to read still.

                                                                         - Ankit