Re: Copying property information

[Tim Janik <timj gtk org>]

On 25 Aug 2001, Owen Taylor wrote:

> 
> > > 50212  Copying param information is not necessary [X]
> > >   Notes:    Alex is looking into quantifying the wastage here.
> > >   Puntable: 
> > >   Breakage: Theoretical, probably not actual.
> > >   Time:     5 minutes + time to decide
> > 
> > the time estimated here is a gross misguess. issues involved:
> > 1) API consistency, we don't take over user strings anywhere in
> >    our API without loud flagging of doing so, examples:
> >    g_quark_from_static_string(),
> >    g_value_set_string_take_ownership()
> >    so if we change current matters at all we basically have two options:
> >    - we silently assume that the strings passed into current API are
> >      static and don't duplicate them. this will raise millions of
> >      questions on why we don't do the same in other possible places.
> >      i.e. special flagging mentioned above (g_querk_from_static_string())
> >      becomes pointless, and duplicating strings passed in to
> >      gtk_type_unique(), g_type_register_static() or
> >      g_type_register_dynamic() also becomes pointless.
> >      especially the latter one will be an issue however, since frequently
> >      the string passed in to g_type_register_dynamic() will come from
> >      unloadable data sections.
> 
> As you are well aware, I'm not suggesting that we start not copying
> all strings passed in. I'm suggesting that a little bit of documented
> inconsistency may be worth it to save 30k of memory per program.
> 
> (Yes, this figure was for all widgets, so an overestimate, but our
> description fields and sets of properties are not at all complete, and
> people  will be using widgets from other libraries as well, so it
> is an underestimate as well.)
> 
> >    - we flag g_param_spec_int() and friends as in other API, this will
> >      produce monsters of function names however, e.g.:
> >      g_param_spec_int_static_strings()
> >      these could at least be provided in parallel to existing API
> >      g_param_spec_int() so change can occour gradually.
> 
> The change that would occur "gradually" would be running a single
> sed script over GTK+. Which is, of course, why it's not that great
> an idea. Why should the function that people are using all of the time
> function be named something like g_param_spec_int_static_strings()?

well, why do we do the same for the commonly used g_quark_from_static_string()?
to convey the special string semantics of that function.

> > 3) the breakage involved won't be huge for gtk proper i assume, but i
> >    guess there's a bunch of (plugin) code in beast that'll have to
> >    change if we broke semantics of currently existing functions
> 
> I very much doubt that plugins in beast have properties that outlive
> the classes they are attached to.... I suppose there is the theoretical

there are plugins which do create pspec name/blurbs on the fly and free
those after creating param specs from it.

> Spending 300-400 bytes of malloc'ed memory plus time overhead) to hold information
> that we need NEVER for a normal programs seems pretty excessive.
> 
> My conclusion from this is that we really need a way to look up property
> names and descriptions lazily. A quick suggestion would be:
> 
>   g_type_set_doc_file (GTK_TYPE_WIDGET, OBJDOCDIR G_TYPE_SEPARATOR_S "gtkwidget.objdoc");
> 
>   g_object_class_install_property (gobject_class,
> 				   PROP_NAME,
> 				   g_param_spec_string ("name", NULL, NULL,
> 							NULL,
> 							G_PARAM_READWRITE));
> 
> And add g_param_spec_get_nick/blurb() that looks up the information frmo the .objdoc file
> for paramspec->owner_type.
> 
> <od:class name="GtkLabel">
>   <od:textdomain domain="gtk20"/>
>   <od:property name="name">
>     <od:nick>Widget Name</od:nick>
>     <od:blurb>
>       The name of the widget
>     </od:blurb>
>   </od:property>
> </od:class> 
> 
> (Yes, that could be done as sexps, if you really want to fight the standardization tide.)

"sexps"?
i basically like the idea of looking up doc strigs lazily, however i don't at all
like the type of markup you suggest above. considering that:
1) such doc files need to be easy to write so people actually suplly them
2) they need to be easy to parse (also for code) and quick to scan, after
   all, g_param_spec_blurb() will want just one string from the doc files,
   something like:
   (GtkWidget
     (GParamSpec "name"
       (nick "Widget Name")
       (blurb "The name of the widget")
     )
   )
   will be way faster to handle, is more compact, and i could cook up a
   _fast_ parser (which just skip-scans over unrelated portions, such as
   (GtkLabel ...) or (GParamSpec "foo")) for this in about an hour.
one problem i see with this is finding yet another install-dir for the doc
files to go, and have this mechanism supported by non-gtk-proper param spec
using code as well.
remaining questions i have on this are:
- should we "cache" strings already read in from doc-files in pspec->{blurb|nick}
  (probably yes, so we can hand them out as "constant" strings)
- is this leading towards having seperate doc files per language, or do we
  want to have a single doc file handling multiple languages?
  either way, this means translators have to figure a new doc file concept

> In fact, I believe this is the right way  to do things, so I'm willing to concede
> on the issue of copying the strings for g_param_spec_string() ... the wins for
> not copying there are small compared to what we can get by lazily looking up the 
> nick/blurb.
> 
> The only thing I think we can't punt on this "move docs to files" issue is to
> add the accessors for nick/blurb and mark the corresponding fields private. If
> we don't do that, then we can't add lazy lookups later.

yes, we should add those now and nuke current ->blurb and ->nick accesses.

> 
> Regards,
>                                         Owen
> 

---
ciaoTJ