On Tue, 2014-02-18 at 18:49 +0100, Andreas Färber wrote: > Am 18.02.2014 18:26, schrieb Paolo Bonzini: > > Il 18/02/2014 18:11, Marcel Apfelbaum ha scritto: > >> It is used to replace qemu_opt_get_bool that provides a > >> parameter for a default value. In this case we need to > >> differentiate "no value" from "false." > > > > But what would the getter return in that case? If possible, it's better > > to initialize to the default value in an instance_init method. > > Another issue I see is that it's currently a valid use case to use a > setter in instance_init to set default values. Doing so would flag the > property as set with this patch. Hi Andreas, thank you for the review!
As I replayed to Paolo, this does not contradict the patch's aim. Meaning, if you have a default for all cases, is ok to init it and make it "set". The interesting case is if you have 2 places: one that you want the value to be "x" if is not set, and other place that you need "y" if is not set. > > To me it sounded like a concept similar to component-oriented IDEs where > non-default values are shown in bold. We'd need a QMP API for that > however, and we'd need to reset properties in instance_post_init to > unset then (globals would be considered unset in that case). I thought about it, but it seemed to me over-engineering *for my case*, where all I need to know if the user supplied the value or not, not need to "unset" it. > > Another aspect is that dynamic properties are slightly awkward, if we > think of setting the rtc, which then advances and reads back differently. Sadly I am not familiar with the "rtc", but as I explained before, I don't need the "repeatedly set/unset" use-case. Thanks, Marcel > > Regards, > Andreas >
