[PyQt] Is the result of SIGNAL() a constant?

[Phil Thompson]

On Wednesday 09 January 2008, Giovanni Bajo wrote:
> On 1/9/2008 4:03 PM, Phil Thompson wrote:
> > On Wednesday 09 January 2008, Aaron Digulla wrote:
> >> Quoting Phil Thompson <phil at riverbankcomputing.co.uk>:
> >>> What about...
> >>>
> >>> foo(const QString &)
> >>> foo(QString *)
> >>
> >> Can you give an example with two signals with the same name and such
> >> parameters? I can't imagine to see that for any single class. It
> >> *might* happen with signals from different classes but there, we have
> >> a clean slate, so I don't think it's an issue unless you can prove me
> >> wrong.
> >
> > I don't have a real example, but that's not the point. The point is that
> > they are different as far as Qt is concerned and so both need to be able
> > to be represented in the same class (even though the programmer that
> > designed the class needs to be shot).
>
> But given that such users can still obtain the same features
> (auto-completion, etc.) through usage of constants:
>
> class Foo(QObject):
>      SIG_FOO_1 = SIGNAL("foo(QString*)")
>      SIG_FOO_2 = SIGNAL("foo(const QString &)")
>
> What is exactly the advantage of supporting this feature out-of-the-box
> in PyQt?

Very little if that's all it was.

I was thinking of introducing a new object that could be bound to a class 
instance so that you could drop the first argument to connect(). For 
example...

    self.connect(baz.foo_QString, self.bar)

It would be nice if you could somehow drop the args if there was only 
one "foo" signal - but that has obvious dangers with future changes to the Qt 
API.

Or even just add SIGNAL as a method to QObject and retain the current method 
of specifying arguments, ie...

    self.connect(baz.SIGNAL("const QString &"), self.bar)

As I said, I haven't thought it through yet.

Phil