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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
