On Wed, Mar 01, 2017 at 09:55:03AM +0100, Martin Kletzander wrote: > 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. I didn't think about that specific case too much. Considering the integration with the access control code, however, the access control driver needs to obtain 1 or more identifying attributes from an object to serve as an "identity" against which access rules are written. Rather than having the access control code know about specific objects, you could invent a "virObjectIdentity" struct which contains a generic list of key+value pairs and then define an virOobjectIdentifier interface which contained a single method that returned a virObjectIdentity instance. This would decouple the access control code from the specific config classes we use. > 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. Any particular parts you are thinking about ? Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
