Clarify status of partially special-cased, partially boxed types
@gcampagna
Submitted by Giovanni Campagna Link to original bug (#725509)
Description
Currently there are two boxed types that are special cased "asymmetrically". They are GClosure and GBytes, and the asymmetry is that argument conversion from JS uses native types (Function and ByteArray resp.), while conversion to JS uses normal boxed types.
The result is that one can get a JS object with which he can do nothing, because argument marshalling will always reject it.
There are multiple options here. One is pure JS marshalling: we always special case GClosure and GBytes to Function (or null, if the GClosure is not from gjs) and ByteArray. Another is pure boxed marshalling: we keep the structure as boxed types, and we make sure (through manual binding/overrides) that one can build a boxed wrapper from the native JS type. Not sure this is compatible with existing code, though. The third one is liberal marshalling: we keep the structure as boxed types, but we accept also the native JS types.
Note that there are four marshalling points: from GArgument, to GArgument, from GValue, to GValue. Consistency should be preserved, as much as possible. This is particularly important from the POV of documentation, which right now refers to ByteArray for GLib.ByteArray and GLib.Bytes without distinction, and I locally modified to say Function in place of GObject.Closure. Pages for GLib.Bytes and GObject.Closure are also missing (not because they are not generated but because I though they were not relevant).
Also note that the decision need not be the same for both. GObject.Closure could benefit from liberal marshalling, because one can technically .invoke() a C closure this way (and it shouldn't crash). GLib.Bytes OTOH benefits from pure JS marshalling, because the only useful thing one can do with a Bytes boxed is call toArray() on it.