Software evolution according to applications of “maybe” containers (nullable data types)

[elfring (Markus Elfring)]

I became curious again to improve the software situation another bit around the usage of “maybe” containers.

Would you like to add any information to related feature requests?

See also further information sources:

• Description for the GVariant type system
• Constructing an empty maybe GVariant object based on a previous GVariant object
• Support for “maybe” containers (nullable data types)

[pwithnall (Philip Withnall)]

The feature request that Markus is talking about is this one: https://gitlab.gnome.org/GNOME/glib/-/issues/2267

[arnaudb]

I’m quite sure that would be useful somewhere in Dconf Editor, as it’s a place where GVariant are used and abused in every way possible. But that should not exactly count as a proof the method would be useful in everyday cases.

[elfring (Markus Elfring)]

But that should not exactly count as a proof the method would be useful in everyday cases.

Such a view is fine.

I imagine that empty GVariant maybe objects will occasionally be needed in data models.

[zbrown (Zander Brown)]

In general I see the benefits of “maybe” types but in GVariant it’s kinda nasty given they are incompatible with dbus

[elfring (Markus Elfring)]

@zbrown

… but in GVariant it’s kinda nasty given they are incompatible with dbus

Do software development challenges need further clarification according to D-Bus applications?

[zbrown (Zander Brown)]

@elfring

Do software development challenges need further clarification according to D-Bus applications?

Honestly no idea what your saying here

[elfring (Markus Elfring)]

@zbrown

Honestly no idea what your saying here

• Can “maybe” containers be supported by the type “VARIANT”?
• How do you think about a limitation for the message depth according to the D-Bus specification?
• Would you like to provide additional programming interfaces for working with nullable data types (as they are known also from SQL databases)?

[zbrown (Zander Brown)]

@elfring

Can “maybe” containers be supported by the type “VARIANT”?

Potentially - You could use the wrap-in-array trick but that’s adding slightly magic behaviour and other dbus clients won’t desugar it (in fact I’m not sure gio could safely either?)

@elfring

How do you think about a limitation for the message depth according to the D-Bus specification?

Off-topic really

@elfring

Would you like to provide additional programming interfaces for working with nullable data types (as they are known also from SQL databases)?

Yes I’m well aware of NULL

[elfring (Markus Elfring)]

@zbrown

Potentially - You could use the wrap-in-array trick but that’s adding slightly magic behaviour and other dbus clients won’t desugar it (in fact I’m not sure gio could safely either?)

How does such a view fit to the type code “109 (ASCII ‘m’)” in the summary of D-Bus types?

[zbrown (Zander Brown)]

@elfring

How does such a view fit to the type code “109 (ASCII ‘m’)” in the summary of D-Bus types?

Category	Conventional Name	Code	Description
reserved	(reserved)	109 (ASCII ‘m’)	Reserved for a ‘maybe’ type compatible with the one in GVariant, and must not appear in signatures used on D-Bus until specified here

So the definition is “nothing at all, but maybe one day do whatever GLib does - until then it’s invalid”

Thus whatever GVariant does, even if incompatible with previous versions GLib releases, is fully compliant with the spec

[elfring (Markus Elfring)]

@zbrown

Thus whatever GVariant does, even if incompatible with previous versions GLib releases, is fully compliant with the spec

Are any solution approaches still waiting for the final acceptance?