Re: Function completion for GVariant maybe types?

I would like to achieve a mapping of nullable objects to indeterminate
checkboxes for example.

A GVariant with 'maybe' type seems far too complicated for this.


I find that "GVariant" provides a general interface for the handling of nullable
data types.

I'd use an integer holding a tristate enum, { NO, INDETERMINATE, YES } (or
possibly a pair of booleans, to match how GtkCheckButton works).

Why do you prefer to use an enumeration instead of the other general application
programming interface?

If you need variants for some reason, { GVariant of type 'b' with value
FALSE, NULL, GVariant of type 'b' with value TRUE } is also a perfectly
good tristate.

I agree in principle. Now you try to reduce my request to a special case while I
am still looking for a more general solution.

If, for some reason, you absolutely need non-NULL variants with type
'mb' ("maybe boolean"), then you already know that your data model is
that you have variants of that type; so you can just make one of these
objects whenever you need a new variant, and you're done:

I do not think that I can refer to such preallocated objects if I would like to
reuse a template class like "Gtk::TreeModelColumn".

There's no need to add functions to GLib for this; and in the time
you've spent arguing about it, you could have implemented all three of
those possibilities and possibly more, chosen the one you liked best,
and got on with whatever high-level problem you were solving.

I have got still a different opinion here which I tried to demonstrate in a
draft for the function "g_variant_new_nothing_from_type".

If your data model is "I have a variant, and I don't really know what it
means" then... you don't really know what it means, and you can't do
anything particularly useful with it until you find out.

I disagree to your conclusion here. - I would like to copy the data type
information from the contained value into a new "Nothing GVariant" in an
efficient way. I do not really want to know the concrete copied data type if I
would like that this operation will be supported in a generic way so that it can
be reused by other class libraries like "glibmm".

Model-view-controller programming shouldn't be an excuse for speculative
generalization. Don't make things more complicated than they need to be;
software is usually quite complicated enough already.

I see opportunities for further fine-tuning and improvement of the involved APIs.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]