Also I didn't want the "overhead" of converting it to a virObject only to convert it later to the newer object. I mean I could now, but I have this goal of making all these driver objects use the same object around the same time. Some convert more easily since they already use virObject - others are a bit more effort.
Still even if I convert it to a virObject now, that's not going to be done in "this" patch...
Fair enough. It's just that whenever I see virSomethinObj I expect it to be derived from virObject. Thus I can use virObject APIs. And as for the "overhead" - I think that it'll be goot if all the objects that you will make use the new "listable" object (or whatever it is going to be called) already have common ground => are virObject already (or something derived from it). At least that's how I view these patches. What do you think? Here's the deal, I'll give you ACK on this and you'll send 9/8 to convert this to actual virObject?
I understand your point, but it's not like I invented virInterfaceObjPtr during this series either... Guess I didn't see the value in creating the OnceInit/Dispose stuff only to see it removed when the "listable" object comes along and makes it unnecessary, but I'll send 2 more patches shortly. John FWIW: A listable object would have both @active and @def, thus rendering the local object obsolete because of this code in virClassNew: } else if (parent && objectSize <= parent->objectSize) { virReportInvalidArg(objectSize, _("object size %zu of %s is smaller than parent class %zu"), objectSize, name, parent->objectSize); return NULL; } There'd be no elements in virInterfaceObj other than the @parent, so there's no use for OnceInit and friends. Yes, I went there during development ;-)