Add FlValue

[robert-ancell]

FlValue is a lightweight object used to contain the value types that Flutter
uses on platform channels.

[robert-ancell]

There's some discussion in #18118 about how custom data types would be represented in a FlValue (in a following PR).

[stuartmorgan-g]

A few small things, but generally looks good if we keep this structure.

One high-level question though (which I think you may have touched on in the other PR, but since I'm not familiar with all the GLib APIs I'm not sure): how much overhead would it add to use existing (and I assume standard?) collection types like garray and g_hash_table? One of the design goals of the C++ verison of this class was to use standard library collections so that people could use all the normal collection APIs they are already familiar with, instead of having to learn a new, more limited API surface, so I'm wondering how feasible that would be here.

[robert-ancell]

The two main used data structures in GLib are GPtrArray (list) and GHashTable (map). They both don't have any type information and just use pointers for the data. Often the data is an object with an unref function provided. Because there's no type safety you generally only see these used for output (a docstring gives the element-type inside these). Using them for input is risky as the user has to get both the type correct and set the appropriate destroy notify (or not). The library can't handle any errors in these cases.

They're also a pain to make, the equivalent code would be:

// With FlValue native

g_autoptr(FlValue) list = fl_value_new_list();
fl_value_list_append_take(list, fl_value_new_string ("foo"));
fl_value_list_append_take(list, fl_value_new_int (42));

g_autoptr(FlValue) map = fl_value_new_map();
fl_value_map_set_take(list, fl_value_new("name"), fl_value_new_string ("foo"));
fl_value_map_set_take(list, fl_value_new("value"), fl_value_new_int ("42"));

// With GPtrArray/GHashTable

g_autoptr(GPtrArray) list = g_ptr_array_new_with_free_func(fl_value_unref);
g_ptr_array_add(list, fl_value_new_string ("foo"));
g_ptr_array_add(list, fl_value_new_int (42));
g_autoptr(FlValue) value = fl_value_new_list(list);

g_autoptr(GHashTable) map = g_hash_table_new_full(g_direct_hash, g_direct_equal, fl_value_unref, fl_value_unef);
g_hash_table_replace(map, fl_value_new("name"), fl_value_new_string ("foo"));
g_hash_table_replace(map, fl_value_new("value"), fl_value_new_int ("42"));
g_autoptr(FlValue) value = fl_value_new_map(map);

[robert-ancell]

I did consider helper functions to build lists and maps from GPtrArray and GHashTable but I honestly don't think there'd be much demand for them and the risk of encouraging programming errors is too great. We could always add them later if required. We could consider adding a GVariant to FlValue conversion (which is provided in Json GLib for example), but again I think the programmer error risk outweighs the value.

[robert-ancell]

I made one final change to the names of the functions, e.g. fl_value_new_int is now fl_value_int_new and fl_value_map_set is now fl_value_set. This is because I was originally thinking of exposing different structures for each subtype of FlValue, but that is no longer the case. The naming is important as it allows language bindings that have constructors to represent this as FlValue.int(42).

[stuartmorgan-g]

The two main used data structures in GLib are GPtrArray (list) and GHashTable (map). They both don't have any type information and just use pointers for the data. Often the data is an object with an unref function provided. Because there's no type safety you generally only see these used for output (a docstring gives the element-type inside these). Using them for input is risky as the user has to get both the type correct and set the appropriate destroy notify (or not). The library can't handle any errors in these cases.

Okay, makes sense then. I was assuming there would be something ubiquitous (more along the lines of std::vector) that it would be annoying not to interoperate cleanly with, but if that's not the case this looks good.