Re: GLib parameters

[David Benson <daveb idealab com>]

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).
...
> 
> * 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.

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]

[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.