DBus Extensions

[Simon McVittie]

On Sun, 12 Aug 2007 at 23:14:41 +0100, Matthew Johnson wrote:
> I'd like to weigh in and say that I am not keen on anything being
> nullable, or arbitrary 'maybe' types. I think the only thing which is
> really necessary along those lines is empty variants (I'd like to say
> variants can only contain a real type or nothing, not another variant. I
> see a whole lot less need to be able to nest them than I do to have
> empty ones. Maybe variant(variant(int 0)) could be a code for
> variant()).

Chiming in from dbus-python's perspective: I go to great lengths to
support nested variants, but I'm often not sure why. If we were to rule that
in a portable subset of D-Bus, arbitrary variant nesting didn't need to be
distinguishable from a single level of variantness, I'd be very happy. If we
were to define a convention that variant(variant(int 0)) or something mapped
to NULL (or None, in Python) at the same time, that'd be good too (I'd go for
variant(variant(bool False)) but maybe that's just me).

At first glance it looks easy to support Maybe in the current
dbus-python API, but in fact, to do so you'd either have to use some
awkward wrapper class, or use an object that isn't None for the
"NULL-like" case (violating least astonishment), or (again) drop support
for distinguishing between different levels of variant nesting.

	Simon