introspection

[Simon McVittie]

On Thu, 25 Jan 2018 at 19:51:59 +1300, Lawrence D'Oliveiro wrote:
> On Wed, 24 Jan 2018 18:00:28 -0800, Thiago Macieira wrote:
> > In any case, depending on runtime introspection is usually bad coding 
> > practice.
> 
> Wonder why it was part of the spec, then?

It's a debugging/development feature for use by generic tools that
cannot be expected to have domain-specific knowledge. For example,
the interactive D-Bus debugger "D-Feet" uses it to display object trees
and their methods, and the gdbus(1) tool supplied by GLib uses it for
tab-completion. You can think of it as the D-Bus equivalent of DWARF
debug symbols: they're very useful for gdb and valgrind, but if C/C++
application code relies on introspecting the libraries that it uses via
their debug symbols, then something has gone horribly wrong.

Clients that *do* have domain-specific knowledge (anything that isn't a
debugging tool) should avoid relying on introspection - their
domain-specific knowledge should ensure that they don't *need*
introspection, because they already know what to expect. For example, an
MPRIS2 client already knows what the MPRIS2 interfaces look like, and
doesn't need Introspect() to tell it.

It was also less clear at the time introspection was designed (we're
talking about more than 10 years ago) how bad an idea it was to use it
outside debugging tools: one major "production" user of introspection is
dbus-python, which is almost as old as dbus, and is unable to stop using
introspection to guess types without it being a major compatibility break.

    smcv