[Kde-bindings] Re: AW: AW: [Kde-perl] PerlQt port for Qtopia / Zaurus?

[Richard Dale]

On Sunday 26 January 2003 3:11 pm, Richard Dale wrote:
> On Sunday 26 January 2003 1:40 am, Ashley Winters wrote:
> > However, in never-never land, you'll notice something Bad can happen.
> > Consider this thought experiment!
> >
> > class QFoo {
> > public:
> >     void insertThing(const QString &name, QThing *object, const char
> > *);
> >
> >     // Note: the 'receiver' isn't a QObject! Read on for implications
> >     // It's a subclass of QObject, and that's 100% legal.
> >
> >     // Secondly: the 'member' argument is unmarked. You'd have to code
> >     // in by hand that the second object needs a slot proxy and
> >     // the third argument is a signal/slot member
> > };
> >
> > # From PerlQt:
> > $foo->insertThing('&Foo', $object, SLOT 'whatever()');
> >
> > In order for insertThing() to connect to the proper slot, PerlQt would
> > have to (transparently, AND specified by hand) pass $object's ProxySlot
> > object to insertThing(). However, it's perfectly legal for
> > insertThing() -- written in C++ -- to call
> > object->thingSpecificFunction(), which would die on a proxy slot
> > inherited from QObject. Creating 100 little subclasses of all the
> > QObject child classes for signal/slot information is impractical, even
> > if that could fix it (which it wouldn't).
>
> Interesting problem - I hadn't thought of that. I not sure if it happens in
> practice in Qt/KDE. Maybe there are few enough examples that it could be
> got round by hacking/special casing the affected methods.
Yes, it does happen, now I think about it in quite a few of those 
'insertThisOrThat()' methods. I've worked round the problem by hand coding 
calls the the underlying C++ instance, rather than the slot proxy. So that is 
a drawback in practice for slot proxies - you're quite right - more plus 
points for the 'use the metadata' technique..

-- Richard