>>
>> 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 ;-)
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
