GObjectification of protocols
a at nevitus.org
Sun Aug 18 15:52:15 EDT 2013
On 19 August 2013 01:00, Eion Robb <eion at robbmob.com> wrote:
> If you split into multiple smaller interfaces, you'll still need to check
> for specific functions as not all of them might be provided for an
> interface, eg not all chat features might be able to be implemented.
That is true. I am currently working on a single interface only, but it would be
a trivial task to split it into smaller interfaces if required at any point.
Also, to avoid retrieving the interface from a protocol every time we want to
use a protocol function, I will be adding convinience functions that do the ugly
work for us (this also means we won't have to check if a protocol can do
something before doing it - just call the function directly, the function will
worry about whether its implemention exists or not).
This makes using smaller interfaces for convinience not necessary, but it may
still be appealing if we want PurpleProtocolInterface to not be so huge.
> Is it possible to set the function pointers using a similar system as you
> have for the plugin information (with the key-value pairs), or does that not
> good form in a gobject system?
The key-value pairs are provided during instantiation of an object, not the
type. So, everytime when creating an object of XMPPProtocol (protocols may be
unregistered and registered again and again by plugin reloads in case of
third-party stuff), we would need to provide all the functions. And then when
creating an object of GTalkProtocol, we would again have to provide all the
functions to instantiate that protocol object.
However, by using interfaces, we set the functions during the initialization of
the type. So, when the XMPPProtocol type is initialized, its functions are set.
And if GTalkProtocol has to inherit XMPPProtocol, it has to set only those
functions in the interface that are different from XMPPProtocol's functions,
since XMPPProtocol's type knows what it implements.
More information about the Devel