>
> 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 ;-)