[Bug 59024] Think about a more introspectable way of doing mixins

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=59024

--- Comment #2 from Simon McVittie <simon.mcvittie at collabora.co.uk> ---
(In reply to comment #1)
> 6) tp_foo_mixin_init_dbus_properties(GObjectClass*): is it possible to call
> in class_init in binding languages? what are the alternatives?

If necessary, we can teach the TpDBusPropertiesMixin to search a per-instance
list before the per-class one.

I have a work-in-progress branch which reduces it to:

* implement TpExportable with no methods (introspectable, I think)

* call Tp.DBusPropertiesMixin.implement_interface(...) from class_init
  (not introspectable)

* call Tp.DBusPropertiesMixin.init(self) from __init__ or equivalent
  (introspectable, I think)

> 7) tp_foo_mixin_iface_init(): Can we give functions to implement the dbus
> ifaces in a subclasses not in C?

No, but we can use TpExportable.

> 8) tp_foo_mixin_do_something(): Will g-i understand that this is a function
> on TpBaseConnection object? Will I be able to do
> base_connection.do_something()?

No, you'll have to do Tp.FooMixin.do_something(self). I don't think that's *so*
bad.

We can use GInterfaces for syntactic sugar if necessary? If you implement
Tp.FooMixable with a foo_do_something() method, you can call
self.foo_do_something() (really tp_foo_mixable_foo_do_something() in C). We
could use the same GInterface to hold the necessary vfuncs for the actual
implementation.

> Maybe crazy, but I'm wondering if we should make those mixins really part of
> TpBaseConnection, but optionally initialized.

I would like to keep this as a last resort: if all our objects are this tightly
coupled, replacing one becomes really annoying.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.