"Daniel P. Berrange" <[email protected]> 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.
