On 11/18/2014 09:44 AM, John Snow wrote:
>> Is it worth using type inheritance, as in:
>>
>> { 'type': 'BlockDirtyBitmapAdd',
>> 'base': 'BlockDirtyBitmap',
>> 'data': { '*granularity': 'int' } }
>>
>
> Strictly speaking, I would argue against inheritance here because
> "BlockDirtyBitmapAdd" is not "isa" "BlockDirtyBitmap". It's more of a
> "Hasa" relationship.
Fair enough.
>
> At any rate, I tried to implement this for giggles to see if I could,
> and ran into the following issue with which I'd be curious to get an
> answer for.
>
> As an example, If you have some type:
>
> { 'type': 'example',
> 'data': { 'foo': 'int' } }
>
> And an extension of it:
>
> { 'type': 'academicExample'
> 'base': 'example',
> 'data': { 'bar': 'str' } }
>
> How would you write a command that expected both "foo" and "bar"?
> The following doesn't seem appropriate (the generated code SKIPS the
> base fields, which leads to missing arguments in the prototype:
>
> { 'command': 'academic-command',
> 'data': 'academicExample' }
Ouch. Sounds like a bug in the code generator. Obviously, someone will
have to patch that (and add a testsuite entry to make sure it doesn't
regress) before we can rely on it.
>
> ...
>
> {
> .name = "academic-command",
> .args_type = "foo:i,bar:s",
> .mhandler.cmd_new = qmp_marshal_input_academic_command,
> },
>
>
> The generated prototype appears to skip the "foo" argument, including
> only the arguments associated with the base type, in this case, 'bar'.
>
> Do we support this kind of use? I didn't see it in-use currently, but I
> only gave it a cursory skimming.
We supposedly document it as working, but as no one is using it
(including no testsuite entry), I'm not surprised that it doesn't work yet.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
