make _dbus_type_to_string public?

[Simon McVittie]

On 24/12/13 10:15, Andrew Cann wrote:
> For clarification, _dbus_type_to_string just takes a type code and returns a
> string desription of that type. So
>     _dbus_type_to_string(DBUS_TYPE_STRING) -> "string"
>     _dbus_type_to_string(DBUS_TYPE_ARRAY)  -> "array"
>     etc.

I don't strongly object to making this into public API, but describing
types a typecode (character, int) at a time is not amazingly useful: the
general case is that you're looking at entire type signatures, either a
single complete type (examples include "u", "a{sv}", "aa(xtd)") or a
signature consisting of zero or more single complete types (examples
include any of the single complete types I listed, "", "a{sv}as",
"aa(xtd)a{sv}").

I would even say that, with hindsight, the fact that DBUS_TYPE_STRING (=
's') has a simpler name than DBUS_TYPE_STRING_AS_STRING (= "s") was a
mistake. I prefer GVariant's more string-centric approach, in which
GVariantType (basically a string, made up of members analogous to
DBUS_TYPE_STRING_AS_STRING) is the primary type, with the GVariantClass
enum (with members analogous to DBUS_TYPE_STRING) very much secondary.

I generally put type signatures (strings) in my debug output whenever I
need it to talk about types. I would typically expect heavy D-Bus users
to be able to understand most signatures "by eye" anyway[1],
particularly common constructs like a{sv}.

To stringify an entire signature like aa(xtd) you'd really need to
understand enough of the type system to be able to say things like array
of (array of (struct (int64, uint64, double))), which, while useful, is
a new function that hasn't yet been written.

Playing devil's advocate for a moment (because sometimes a maintainer's
job is to say "no"), one argument for this function not being API is
that I wouldn't want to guarantee that its output for a given input will
never change (e.g. if we adopted GVariant terminology, re-branding
"struct" to "tuple"). Naming it dbus_type_to_debug_string() would go
some way towards mitigating that.

Regards,
    S

[1] the main gap in my own knowledge is that I can never remember which
    of the 64-bit integers is signed and which is unsigned (for the
    record, "x" is signed and "t" is unsigned)