Re: [libvirt] [PATCH RFC 2/9] conf: Introduce virPoolObj and virPoolTableObj and PoolObj API's

On Tue, Feb 28, 2017 at 04:39:52PM +0000, Daniel P. Berrange wrote: > FWIW, the virObject framework as it exists today was just the bare > minimum we needed in order to get a basic inheritance system up and > running in libvirt. I rather expected that we would extend it in the > future to add further concepts, inspired/borrowed from glib (which > is what stimulated my creation of virObject in the first place). In > particular I could see > > - Interface support - the virObjectListable concept sounds like the > kind of thing that would be suited to an interface, rather than a > subclass, as it lets different objects support the API contract > without forcing a common ancestor which might not be appropriate > This is really interesting and bunch of ideas *how* this would be implemented pop into my mind. I like the overall idea of using more virObject goodness and expanding it so that it can to more. I thing I get why interfaces are more suitable in some cases. Having 'lockable' and 'poolable' interfaces, for example, make it possible to have classes that are lockable, poolable, both, or none of those things without having three intermediate classes to derive from. I do not understand one tiny thing, though. Why is interface good for this one particular occasion when every poolable object will always need to be lockable? I think in this particular case having virObjectPoolable derive from virObjectLockable is pretty reasonable.

One more thing. Can we do something about the static type-safety of virObject APIs in the future? The only idea I could come up with is optional GCC plugin tailored to our usage, but that seems cumbersome.