Re: Questioning non-NULL boxed types

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj gtk org> writes:

> hi all,
> 
> currently we have the behaviour:
> 
> GValue value = { 0, };
> gpointer boxed;
> 
> g_value_init (&value, {G|GDK|GTK}_TYPE_<boxedtype>);
> g_value_set_boxed (&value, NULL); /* this line could be omitted */
> boxed = g_value_get_boxed (value);
> 
> with boxed == NULL, for nearly all boxed types, except for the boxed types
> G_TYPE_GSTRING and G_TYPE_VALUE_ARRAY. for GString and GValueArray, boxed
> will contain either a GString with 0 length or a GValueArray with 0 elements.
> 
> this is achived by the default value initializers of G_TYPE_GSTRING and
> G_TYPE_VALUE_ARRAY automatically supplying default 0-length structures.
> 
> the idea behind this is to allow value types to be created that will never
> be NULL, but always be defined in some default 0-setup, e.g. for LBs that
> would want to map GString onto strings or GValueArray onto arrays and
> didn't allow for "undefined" or "NULL" values thereof.
> 
> this behaviour was implemented for GString and GValueArray mostly as a test
> case for value initializers. i'm now questioning whether we want to keep
> that behaviour, the drawbacks/pros i see are:
> 
> - not allowing NULL is slightly inefficient in setups like:
>   g_value_init (&value, G_TYPE_GSTRING);
>   g_value_set_boxed (&value, my_gstring);
>   since an intermediate 0-length GString is created at g_value_init() time
> - for languages that suppot NULL strings/arrays etc, this behaviour implies
>   information loss, since a NULL GString != 0length GString, same for
>   GValueArray
> + LBs that can't handle NULL strings or arrays don't need to put additional
>   logic into their glue code
> + LBs that can't handle NULL strings or arrays don't loose information over
>   the C API if NULL is not a representable string/array in GValue
> 
> of course this all assumes that there are LBs out there that have problems
> representing NULL strings/arrays, so reports thereof would help in making
> the final decision over this, e.g. perl wouldn't be an issue as it could
> map things as:
> 
> my $mystring = "n-length string";
> my $mystring = ""; # 0-length string
> undef $mystring;   # NULL-string
> 
> i'm not so sure about arrays (i'm pretty perl illiterate ;)

There is no distinction between an 0-length array and an undefined array
in Perl; however, a Perl binding would almost certainly not use a  
array as the mapping for a GValueArray boxed type ... it would rather
use an array reference. (You can't pass an array as a parameter to 
a function, for example.) And an array reference is just a scalar, so
a variable can hold either undef or a array reference. 

Basically, my opinion is that if we get rid of the boxed_init parameter
to g_boxed_type_register_static, then this is a good change. We have
the very simple notion that Boxed types are pointers with a copy/free
function, and can always be NULL. Language bindings can then map all
boxed types in essentially the same way.

It's a nice simplification of the idea of a boxed type.

If we don't get rid of the boxed_init function, then I really don't care
much one way or the other, since I don't have any uses in mind for either
the GString or GValueArray types. There is some danger that boxed types with 
non-NULL boxed_init function might need custom handling in language bindings,
or things may act a little suprising. (Setting a GString typed property
to undef in Perl would not be an error but result to it being set to a
zero-length string.)
 
Regards,
                                        Owen