[Development] RFC: banning _q_slot() in favour of new-style connect()?

[Olivier Goffart]

On Friday 12 October 2012 12:08:59 Marc Mutz wrote:
> On Friday October 12 2012, Thiago Macieira wrote:
> > On sexta-feira, 12 de outubro de 2012 07.27.51, Marc Mutz wrote:
> > > R2: less space used in meta-object
> > 
> > True, but minimal impact.
> 
> QLineEdit has up to seven _q_ slots, vs. up to eight normal ones (exact
> number depends on #ifdefs). But yes, I need to measure whether the
> reduction in the meta-object isn't offset by the extra code for another
> QSlotObjectBase subclass.

Notice that with my proposed patch, there is only one extra SlotObject 
subclass per combinaison of types of arguments.  But how many of those private 
slots actually takes none arguments.  Or maybe one of the basic types.  If you 
account the whole library, that's very few new subclasses.

While the metaobject adds all the introspection stuff for each slots.



> > > Gotchas:
> > > G1. The slot could have been overridden in a more-derived class
> > 
> > Extremely unlikely, which is why they have a _q_ prefix in their names.
> 
> I'm not talking about accidental reimplementations, but intentional ones.

Just mark your function as virtual.

> > > G2. The Private pointer could change in between the connect() and the
> > > emit. Currently, this is transparently handled by injecting a call to
> > > d_func() into the moc-generated code. For new-style connect, such a
> > > situation would require a disconnect/connect pair.
> > 
> > That's even more unlikely to the point I can confidently say it never
> > happens. (remember Q_PRIVATE_SLOT is a private macro, so no one outside of
> > Qt is using it)
> 
> QDBusConnectionPrivate::deliverCall does something 'funny' with
> QDBusContextPrivate (::set()), but I didn't look too deeply into it.
> 
> Anyway, I've used Q_PRIVATE_SLOT in all kinds of projects, including KDE, so
> it's not like no-one outside of Qt is using it.
> 
> Even so: a 'normal' slot (public Q_SLOTS:) would override the Q_PRIVATE_SLOT
> in the meta-object, too, so no Q_PRIVATE_SLOT use is required in the first
> place.

No problems with the suggested patch.



> > > The full solution would be to try to remove all _q_slots() from Qt 5.0.
> > > Seeing as this change could also be done in 5.1, I'd only propose to ban
> > > _new_ _q_slots() from being added.
> > 
> > If we agree on how to use them, yes. The only solution we *can* use is
> > functors, which are hard to use.
> 
> Not harder to use than Q_PRIVATE_SLOT, IMO. More annoying, yes, because of
> boilerplate code (of which Q_PRIVATE_SLOT also has some, mind). Real-life
> example:
> 
> // .cpp:
> struct UpdateAccessibilityOnCursorPositionChanged {
>     QTextEdit *const q;
>     explicit UpdateAccessibilityOnCursorPositionChanged(QTextEdit *te)
> 
>         : q(te) {}
> 
>     void operator()() const {
>         QAccessibleTextCursorEvent event(q, q->textCursor().position());
>         QAccessible::updateAccessibility(&event);
>     }
> };
> 
> vs.
> 
> // _p.h:
> 
> Q_PRIVATE_SLOT(d_func(), void _q_cursorPositionChanged())
> 
> // .cpp
> void QTextEditPrivate::_q_cursorPositionChanged()
> {
>     Q_Q(QTextEdit);
>     QAccessibleTextCursorEvent event(q, q->textCursor().position());
>     QAccessible::updateAccessibility(&event);
> }
> 
> And: the more functional code, the less the (constant) boilerplate code
> matters.
> 
> It's different pattern, but it isn't harder to learn from first principles
> than the Q_PRIVATE_SLOT one.

-- 
Olivier

Woboq - Qt services and support - http://woboq.com