"Daniel P. Berrange" <berra...@redhat.com> writes:

> On Thu, Sep 22, 2016 at 10:36:45AM +0200, Markus Armbruster wrote:
>> Don't make up a description in user_creatable_help_func(), improve the
>> description infrastructure and its use so you get more useful ones
>> there.
>> The existing description infrastructure is just Property member
>> description and object_property_set_description().  Rarely used, so
>> description is generally null.
>> Calling object_property_set_description() more often could be helpful,
>> but to come up with a sensible description string, you need to know what
>> the property does.  Needs to be left to people actually familiar with
>> the objects.
>> Aside: historically, we add properties to *instances*.  All the property
>> meta-data gets duplicated for every instance, including property
>> descriptions.  This is more flexible than adding the meta-data to the
>> class.  The flexibility is rarely needed, but the price in wasted memory
>> is always paid.  Only since commit 16bf7f5, we can add it to classes.
>> Adding lots of helpful property descriptions would increase the cost of
>> instance properties further.
> FWIW, we could easily optimize handling of description strings by
> applying the same trick that GLib has done for GObject property
> descriptions.
> Almost certainly every call to object_property_set_description is
> going to be passing a string literal, not a dynamically allocated
> string. So we take advantage of that and in fact mandate that it
> is a string literal, and thus avoid the strdup() of description.
> We can place a fun game to enforce this at compile time thus:
>  - Rename object_property_set_description() to
>    object_property_set_description_internal()
>  - Add the macro
>   #define  object_property_set_description(obj, name, desc, errp) \
>      object_property_set_description_internal(obj, name, "" desc "", errp)

Cute :)

> None the less, we really should make an effort to switch things
> over to use class properties instead of instance properties, as
> its going to save us allocating a 64 byte struct per property
> per instance

Yes, please.

Related: a way to define a bunch of properties as *data*, i.e. an array
of property descriptions, commonly static.  Reasoning about static data
is so much easier than reasoning about code.

Reply via email to