Re: GLib parameters

[Tim Janik <timj gtk org>]

On Thu, 9 Mar 2000, David Benson wrote:

> This was a very interesting email -- thanks for the food for thought.
> 
> ...
> > procedure types and build the foundation to serialize objects (read/write
> > objects to/from a text stream).
> ...

well, unfortunately, i got no chance to outline object-system related
benefits of such a system in that mail, since it was already getting
far to long ;)

[i'll write some up at a later point though]
the key feature is, once you got a flexible, but still simple
enough to maintain parameter system as the foundation, it really pays
off for implementing all object modifications through the parameter
system. [and keeps object implementations more elgeant, consistent
and therefore maintainable]
so you can basically do generic state recording (for undo) and
serialization. eventhough gtk objects have an argument system, it is not
used to route all object modifications through it, which prevents us
from e.g. default-initializing an object from the rc-files and other
cool goodies.

> > * GtkArg/GtkObject have some general-use problems with constructor arguments,
> >   though this is independant of the GtkArg->GParam transition, a satisfying
> >   solution still has to be worked out.
> 
> Experience has shown [ie gdam] that these two are related heavily.

well with independant here i meant, that we can concentrate on getting the
parameter system going, and still add construct-args functionality at a later
point, not affecting the initial design (its merely a flag-value issue as
outlined below).

> I've generally found that what is done by constructor arguments
> can usually be done by the init function.
> 
> In gdam I've found it most convenient to distinguish
> just one class of argument:
> 
> 	- `vital' arguments are those that represent the state
> 	  of an object.  Under most circumstances, they are sufficient
> 	  to reproduce the state of an object.
> 
> 	  This may be a bogus notion in some frameworks, because
> 	  not all objects can guaranteed reproduction of state,
> 	  however it is useful in many contexts, then serialization
> 	  can be done on a per argument basis.
> 
>           In gdam, I've forced all objects to be reconstructable
> 	  from their vital arguments.  Then I directly save/load
> 	  them from xml.
> 	  
> Nonvital arguments generally fall into a few categories:
> 
>         - arguments maintained as a convenient virtual interface
> 	- arguments which do computations when retrieved
> 	- arguments which are basically 1-to-1 functions on the vital arguments
> 	- arguments used as a hack to do function calls [ie not really state]

yeah, i have a similar distinction in BSE as well, a BseParam uses the
flags field for certain hints like GUI_ONLY or STORAGE_ONLY, so i have
non-vital "virtual" parameters as well, for instance

GUI:	 "volume [%]",  int,   0% - 100%
GUI:	 "volume [dB]", float, -40dB - +10dB
STORAGE: "volume",      float, 0 - 1.0 (reflecting actuall multiplication
                                        factor for sample processing)

those parameters all affect the same structure field, and once one of
them is changed, the other two are also flagged as `modified' and code
that hooks up notification handlers to the object is appropriatedly
notified.

this produces pretty nice code since it keeps the distinction of
GUI presentation vs. object state reflection, still maintained by
a genralized object parameter interface.

i've not really used arguments to perform computations in the code though,
since that's really breaking with the "parameter" intend of the system,
and besides, i got the procedure types and sample-value-streams for that
anyways ;)

> [there is also a gdam-specific protocol for binary
> communication of arguments to the server, like the collect
> function...] 
> 
> I think in a general framework it might be useful to
> have the objectclass contain whether it can be reproduced from
> solely its arguments.

that's a good idea actually, but we can persue that further when
discussing GObject (or derivatives) implementations.


---
ciaoTJ