Spec clarification: can a signal and a method have the same name?

[Thiago Macieira]

Simon McVittie said:
>> >Are bindings expected to support a signal and a method in the same
>> >interface having the same name?
>>
>> In Qt, signals and methods are member functions in a C++ class, so they
>> can only exist at the same time if they are overloads of one another
>> (different parameters).

I might add that other implementations of the signal-slot concept make
signals be member objects in a class (basically, a list of target
functions). In those cases, there's no overload possible.

However, Qt encourages signal-signal overload in some cases. For example,
it's common practice to have:
Q_SIGNALS:
    void itemSelected(int index);
    void itemSelected(WhateverType* item);

But that's local (intra-process) stuff. If you follow Havoc's guidelines,
you'll want the signal to be emitted only once over the bus and with the
most information possible. So the exported signal should be the second
form, passing either an object path reference or a struct with the data
itself.

> OK, so Qt discourages and sometimes forbids signals and methods of the
> same name. Good to know. I think between that and dbus-python, if we
> clarify the spec to say you shouldn't have signals and methods of the
> same name, we'll be describing existing practice.

I think we can leave it at the same point where we left overload in
general: the protocol doesn't forbid it, but we discourage using them due
to interoperability issues.

If someone wants an interoperable interface, there should be no overloads,
and this includes overloads between methods and signals (and properties).

For binding developers, this means that you're encouraged to support them
if you can. But if it's not possible, it's not a big deal.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358