Anthony Liguori <anth...@codemonkey.ws> writes: > On Tue, Jul 30, 2013 at 1:39 AM, Markus Armbruster <arm...@redhat.com> wrote: >> Anthony Liguori <anth...@codemonkey.ws> writes: >> >>> This was part of the discussion way back when this all was first >>> introduced. Since everything was open coded and we had to preserve >>> the semantics, that was the only choice we had. >> >> Yes, there is a difference between an optional parameter with a default >> value and one without. >> >> If you got a value QMP clients cannot send, the difference can be >> eliminated: just pass this value to stand for "nothing". This is the >> case for pointers: just pass NULL. Like everybody else does when >> passing "nothing". >> >> When "nothing" is to be interpreted just like a context-independent >> default value, then the difference doesn't matter. The client doesn't >> care, and the function handling the message becomes simpler. >> >> Only when "nothing" can mean different things do you really need both >> have_FOO and FOO parameters. > > Right, and I'm saying that we have cases like this (especially with > bools). Unfortunately, there are places in the protocol that have
No argument there. > tristate values for bool parameters and the behavior is distinctly > different for false, true, and not-present. > > So yes, we could special case those bits and use sentinel values for > everything else. Just realize that we need to handle the above case. Yes, we do, and it's understandable that only the most general case got implemented. >> I can't see why we couldn't introduce default values into the schema if >> we wanted, and use them to simplify generated code. >> >> For pointers, we don't even need schema extensions to simplify away the >> silly have_FOOs. > > Except you have to carefully audit all users to make sure of that. For pointers, the audit should be trivial: change generator to omit the have_FOO, compile, fix up the compile errors (drop have_FOO arguments, replace have_FOO tests be FOO tests), done.
