Spec clarification: can a signal and a method have the same name?
simon.mcvittie at collabora.co.uk
Wed May 23 01:02:17 PDT 2007
-----BEGIN PGP SIGNED MESSAGE-----
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
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'
dbus-python's client-side proxies already support calling
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: OpenPGP key: http://www.pseudorandom.co.uk/2003/contact/ or pgp.net
-----END PGP SIGNATURE-----
More information about the dbus