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

[Marc Mutz]

Hi,

I was wondering whether we should stop using the pattern of declaring 
_q_privateSlots() in favour of connecting to functors or functions directly.

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).
R2: less space used in meta-object
R3: allows patch releases to add or remove code that would formerly have
  required _q_slots().

Gotchas:
G1. The slot could have been overridden in a more-derived class
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.

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.

Opinions?

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions