Re: Private virtual methods

[philip chimento gmail com]

On Sat, Aug 4, 2018, 19:20 Tony Houghton, <h realh co uk> wrote:

On Sat, 4 Aug 2018 at 22:54, <philip chimento gmail com> wrote:

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:

I want it to be overridable, but only visible to subclasses and only intended to be called from the class it's defined in. I didn't realise until now that you can do this with private virtual methods in C++. But in Java you can't override private methods. So does GI's private annotation still allow overrides?

No, it doesn't. However, I believe that *all* GObject virtual methods are only intended to be called from the implementations of either the parent class or subclasses, not by client code.

You could probably add a check in the virtual method that checks that the instance is only of the types that you want to allow.

/**

 * 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);

};

 

OK, what I didn't realise was that the way to document virtual methods is as members of the class, which sounds obvious now. Is it important to document all virtual methods this way, or are the tools that generate gir and typelib files able to deduce the presence of function pointer class members if you use the "virtual" annotation on the corresponding public functions?

The vfunc slot will be deduced in any case by g-ir-scanner, so it will be present whether you document it or not.

About annotating the function pointer types, as far as I know this is a gap in GI's capabilities. What might work is to make the function pointer type a separate typedef, then annotate that:

/**

 * MyObjectPublicSlotType:

 * @etc

 */

typedef void (*MyObjectPublicSlotType) (MyObject *);

...

struct _MyObjectClass {

  MyObjectPublicSlotType public_slot;

...

But I'm not sure if that will work.

Regards,

Philip C