Object paths naming conventions?

[Marcel Holtmann]

Hi Havoc,

> > Your point is that every API contract should use namespacing of object
> > paths to allow multiple APIs in one process. And I agree that is a nice
> > feature to have. However my point is that namespacing the object path is
> > not needed since we do have namespaces within the interface names in all
> > cases that I have seen so far.
> 
> How does a namespace on the interface prevent collisions on instances?

for me the instance is object path + interface name and that has no
collisions when use namespaces on the interfaces.

> > From the client point of view and thus the language binding actually
> > using the API, I think the language object you always refer to is
> > represented by the object path + interface name. Feel free to correct me
> > here, but that is my experience.
> >
> > So why do we need namespaces in the object path and the interfaces. What
> > kind of benefit does it give us?
> 
> The problem is that in say Java or C++, you don't want the object at
> "/" to be like:
> 
>  class DoEverything implements SessionManager, Accessible,
> Application, Foo, Bar Baz {
>     // insert giant boatload of methods here
>  }
> 
> You want separate objects and code modules for the different functions.

Yes, I do want that, but as mentioned above. The actual instance is
represented by the object path + interface name.

The D-Bus interfaces don't allow overwriting, shadowing etc. of method
calls. They have nothing in common with an object oriented programming
model. I would even say they are just another way of namespacing method
names.

Regards

Marcel