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

[Simon McVittie]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 23 May 2007 at 06:37:35 +0200, Thiago Macieira wrote:
> Simon McVittie wrote:
> >A question for the specification gurus:
> >
> >Signals and methods are both identified by a pair (interface, member)
> >where the member part is in the same format for both.
> >
> >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).

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.

> >(The OLPC's DataStore has methods called things like 'delete', which
> >emit signals also called things like 'delete'. I realise this is
> >an unconventional naming scheme - not my choice - but I don't know
> >whether this is something I should be supporting or forbidding in
> > dbus-python. At the moment dbus-python doesn't support this without
> > some awkwardness, or possibly at all.)
> 
> "delete" is also a reserved word in C++. An interface with such a name 
> will fail to compile.

We can't forbid particular interfaces because they use a reserved
word in one of the many binding languages - that would mean what's
allowed changes whenever anyone implements a binding!

I realise some interfaces will be unimplementable or unusable in some
languages, but in my view that's a bug in the binding (not a very major
one, since interfaces that follow the D-Bus naming convention will be
fine).

In dbus-python I've been looking into allowing the @signal and @method
decorators to specify a name that isn't the name of the function, which
would allow Python services to implement a method or signal named after
a reserved word if required, via some syntax like:

@method('com.example', dbus_name='while', in_signature='v', out_signature='i')
def while_(self, stuff):
    # Implements the method 'com.example.while'
    return 123

dbus-python's client-side proxies already support calling
arbitrarily-named methods.

	Simon
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: OpenPGP key: http://www.pseudorandom.co.uk/2003/contact/ or pgp.net

iD8DBQFGU/UJWSc8zVUw7HYRAnMmAJ41aXl+jEveuMqxzC/wV1uHjlIJEACeJgjs
RsSmuyCRe+6xj0Pe+zli92k=
=Pd+w
-----END PGP SIGNATURE-----