[Workman-devel] [PATCH] WorkmanPlugin: make it a public class

[Daniel P. Berrange]

On Tue, Apr 02, 2013 at 03:23:22PM -0500, Josh Poimboeuf wrote:
> Make WorkmanPlugin a public class so that the GObject introspection
> compiler won't complain when we add a WorkmanPlugin as a property of
> WorkmanObject.
> ---
>  workman/Makefile.am      |  2 +-
>  workman/libworkman.sym   |  2 ++
>  workman/workman-plugin.c | 21 ++++++++++++++++++++-
>  workman/workman.h        |  1 +
>  4 files changed, 24 insertions(+), 2 deletions(-)

Hmm, this is something I'm really not at all happy with from
an API architecture POV, because it is causing implementation
details to leak out into the application visible interfaces.

IMHO the root cause of the problem are the changes which have
turned workman-object/consumer/partition into concrete classes.
Originally I had them designed as abstract classes, which just
define the API contract. The glue to the plugin objects would
thus be in subclasses, thus none of the impl would be able to
leak out to the callers. Given the problems highlighted by
this & the next patch, I think we need to move back towards
the original design I had. Make object/consumer/partition be
abtracct and have plugin-consumer/plugin-partition as subclasses
which provide the glue to the plugin.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|