[Kde-perl] Why not proxy slots?

[Ashley Winters]

This is what I get for offering to document. I got asked "why not use
proxy slots?"

Proxy slots suffer from a similar problem as virtual functions, and the
options to workaround are also similar.

The problem: There is no guarantee that a function must take the name
of the slot as an argument, and there's no guarantee that a function
won't try to call a non-QObject method on the receiver.

Neither of these problems is particularly severe, and PyQt gets along
fine without. However, when working with PerlQt-2.x, I encountered
classes which would do semi-evil things with the receiver.

Allow me to demonstrate:

void Class::connectFoo(QWidget *receiver, const char *slot) {
    // note that receiver is a QWidget, while proxy objects are QObject
    if(receiver->ownPalette()) {
        // proxy object croaks when you call QWidget methods
    }
    connect(SIGNAL(mySignal()), receiver, slot);  // works fine
    connect(SIGNAL(myButtonPressed()), receiver,
            SLOT(update());    // no such slot in proxy
    // however, update() has been a slot in QWidget forever
}

There are some reasonable workarounds. First, provide proxy signal/slot
classes for every subclass of QObject (like my solution to virtual
functions). Second, add every possible signal/slot prototype to the
proxy class (quite workable). Third, hack the Qt internals to actually
add the signals&slots to the genuine receiver, without using a proxy
(like Adam's goal for C# virtual functions).

These are hardly showstopping problems, but since I can avoid it
completely by hacking into Qt's guts, I do.

Ashley Winters

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com