org.fd.DBus.Introspectable.EnumerateObjects()

[Lennart Poettering]

On Thu, 13.05.10 11:10, Thiago Macieira (thiago at kde.org) wrote:

> > What does this do?
> > 
> >   It will basically return all child objects of the object called that
> >   implement the specified interface. If the interface string is the
> >   empty string, then it will return ALL child objects, regardless of the
> >   interfaces they implement.
> 
> I agree with this, but I'd swap the "in s interface" parameter with "in b 
> recursive".
> 
> Either you want to know the direct descendants, or all of them.

I see no point in adding this to the function call. In my original
proposal I explicitly let it open whether the function should act
recursively or not. I cannot think of any use case where a client might
want to choose between the two dynamically.

Also, I don't want to force every implementation to support recursive
searches.

> But I don't like giving people the ability to search for an interface. That 
> will lead to bad client code instead.

Will it? It won't!

The interface parameter is necessary simply because this is what most
existing services currently implement. Example: in PA we have GetSinks()
and GetSources(), both of which return their specific kind of object.
systemd I have something similar (GetUnits() and GetJobs()), and CK too
(GetSessions() and GetSeats()) and udisks has something similar too
(EnumerateAdapters, EnumerateDevices, EnumeratePorts, ...). It's simply
how things work: if you want access to an object you need to know its
type in advance, because otherwise you have little use for it. (with the
exception of pure introspection tools like d-feet, which are however
only good for debugging)

What would be bad design is if we don't have this interface parameter:
because then you would get a list of objects where you don't know the
types. So you'd first have to introspect it, parse XML and then figure
out which interface it supports so that you can actually make use
of. And if it doesn't have any interface you speak you'd have to drop it
again.

i.e. what you suggest would force people into code like this:

<snip>
l = o.EnumerateChildren();
for (i in l) {
        if (!i.implements("my.foobar.interface")) 
                continue;

        printf("%s\n", i.name); 
}
</snip>

And that is ugly, in so many ways: it's slow, because we'd hgave to make
at least one call per element, and implements() style calls suck anyway,
and we don't have them, and we need to implement them with XML,
manually. And we go through all elements even if the foobar elements are
just a tiny subset of it.

This is so much better:

<snip>
l = o.EnumerateChildren("my.foobar.interface");
for (i in l) 
        printf("%s\n", i.name);
</snip>

No ugly implements() calls, we only go through the minimal list, no XML
parsing. Sexy. Minimal. Short!

And on top of that this is much more likely what people call anyway.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4