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

[Thiago Macieira]

On sexta-feira, 12 de outubro de 2012 07.27.51, Marc Mutz wrote:
> Hi,
> 
> I was wondering whether we should stop using the pattern of declaring
> _q_privateSlots() in favour of connecting to functors or functions directly.

Makes sense, except that it's of inconvenient use:
 - lambdas: can't use in Qt code
 - functors: inconvenient (need to be out of the class)
 - static member or free functions: will not have access to the target object
 - private member functions: disallowed by Qt coding guidelines

> Rationale:
> R1. the _q_ prefix is just a convention, the slot can still be called
> through the meta-object and still can be reimplemented in more-derived
> classes. With new-style connects, there'd be no slot to call or
> reimplement, so the code would become easier to understand (d/t more narrow
> scope).

Good.

> R2: less space used in meta-object

True, but minimal impact.

> R3: allows patch releases to add or remove code that would formerly have
>   required _q_slots().

Not relevant, since this is already permitted.

> 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.

> 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)

> 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.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20121011/470b2d5e/attachment.sig>