Warn about redefined members of another DBus interface

[poncovka]

The dbus_interface decorator doesn't generate XML specification for members of another DBus interface. It is not easy to discover why these members are not generated, because they are just silently skipped. Show a warning or some debug messages with information about a possible collision with another interface.

@dbus_interface("org.example.Project")
class InterfaceProject(InterfaceTemplate):

    def Set(self, x: Int):
        pass

In the example above, the Set method will not be generated as a member of the org.example.Project interface, because it is already defined in one of the standard interfaces, org.freedesktop.DBus.Properties.

[m-horky]

I looked through the specification and there's no mention that multiple paths on the same interface can't have duplicate method names. Is dasbus just being too strict, or were there some issues with this in the past?

From what I can see in server/interface.py, DBusSpecificationGenerator._generate_interface(), the call to _is_defined() is just not required. Python (cpython at least) will use the latest definition of the function if there are multiple ones with the same name.

Am I missing something and would removing the check fail somewhere else (e.g. if someone tried to register multiple services with different implementation under the same name)? Or maybe the real world of DBus is just not reflected in the spec? I don't really know :)

[poncovka]

I looked through the specification and there's no mention that multiple paths on the same interface can't have duplicate method names. Is dasbus just being too strict, or were there some issues with this in the past?

Yes, this limitation comes from dasbus to avoid the issues below.

From what I can see in server/interface.py, DBusSpecificationGenerator._generate_interface(), the call to _is_defined() is just not required. Python (cpython at least) will use the latest definition of the function if there are multiple ones with the same name.

Am I missing something and would removing the check fail somewhere else (e.g. if someone tried to register multiple services with different implementation under the same name)? Or maybe the real world of DBus is just not reflected in the spec? I don't really know :)

1. The check is necessary to decide whether you define a new DBus method (so it will be specified in the XML of the new DBus interface) or redefine an existing one (so it is already specified in the XML of another DBus interface). Without the check, redefined DBus methods would be always included in the XML of the new DBus interface. You can always skip the XML generator and provide the specification using the __dbus_xml__ attribute. However, there is another issue to consider.

2. Python doesn't allow to define multiple methods of the name name. As you pointed out, it will use the latest definition. It means that this latest definition will have to handle all variants of the method, for example org.freedesktop.DBus.Properties.Set and the Set method from a custom DBus interface. That is doable, but not very pretty.

[poncovka]

Dasbus was not designed to be a perfect tool, because the variety of use cases is too large. However, the code should be flexible enough to allow any necessary modifications.

1. You can overcome the first issue by redefining the DBusSpecificationGenerator._is_defined method or specifying the __dbus_xml__ attribute directly.

2. The second issue can be solved by redefining the ServerObjectHandler._find_handler method and always using the default handler if there is any.