On Sat, Aug 4, 2018 at 11:49 AM Tony Houghton <
h realh co uk> wrote:
The GObject tutorial says you can easily make a "private" virtual method by adding a function pointer slot to a class definition as usual but not providing a corresponding public function. How should this be documented/annotated for gi? Presumably you can't use the name of the non-existent public function, so what should be used for the first line of the comment block?
I'm guessing by "private" you still want the vfunc slot to be overrideable in GI? (If you would not want it to be visible at all, you'd use /*< private >*/.)
I think there's no difference with how you'd annotate the vfunc slots normally:
/**
* MyObjectClass:
* @public_slot: A public vfunc.
* @private_slot: A private vfunc.
*/
struct _MyObjectClass {
void (*public_slot) (MyObject *self);
void (*private_slot) (MyObject *self);
/*< private >*/
void (*really_invisible_slot) (MyObject *self);
};
Also, are abstract/pure virtual methods supported? It could be done by setting the class' function pointer slot to NULL, but gi doesn't seem to have an annotation for abstracts, and a C compiler can't detect attempts to instantiate an object without setting the slots to valid functions. So I'm guessing they should be avoided in code intended to provide a bindable API? Perhaps I should raise a feature request for it?
There's no annotation for this, so no enforcement in the compiler or GI. But what I normally do, is do a null check before calling the function:
if (!MY_OBJECT_GET_CLASS (obj)->public_slot)
g_critical ("You need to implement this vfunc in your subclass");
MY_OBJECT_GET_CLASS (obj)->public_slot (obj);
Regards,
Philip C
