Qt-interest Archive, July 2007
QT_NO_EMIT and QT_NO_KEYWORDS: Why not Q_EMIT?
Message 1 in thread
Hello,
With Qt 4.1, trolltech introduced the wonderful no_keywords option to
allow people to continue to use signals, foreach etc using
non-polluting names such as Q_SIGNALS and Q_FOREACH. However, emit
still has no variant.
I realise from this [1]thread that a solution of sorts is available:
define QT_NO_EMIT and there is no longer any emit keyword. Looking at
qobjectdefs.h it seems like this solution is a throwback to the days
before no_keywords more than anything else.
I propose the following:
o change to the use of Q_EMIT as a non-polluting variant of emit for 4.3.1
o deprecation of QT_NO_EMIT and removal at some later Qt version such as 4.4
I'm only a minor adept at KDE but it seems here that everyone uses
Q_SIGNALS and friends where possible anyway. I'd like to keep some
emit variant around as I wouldn't want to call everything sigFunction
the way slotFunction seems to be the norm ;-)
[1] http://lists.trolltech.com/qt-interest/2001-08/thread00081-0.html
Just a suggestion made on #qt,
Gavin
--
[ signature omitted ]
Message 2 in thread
On 01.07.07 20:34:36, Gavin Beatty wrote:
> I propose the following:
I hope you realise this is the wrong place to send such stuff. Trolltech
does have proper feedback channels for such wishes.
> o change to the use of Q_EMIT as a non-polluting variant of emit for 4.3.1
> o deprecation of QT_NO_EMIT and removal at some later Qt version such as 4.4
>
> I'm only a minor adept at KDE but it seems here that everyone uses
> Q_SIGNALS and friends where possible anyway.
AFAIK thats not quite right, at least I personally use signals/slots
most of the time, except in public API. Which is the kdelibs policy,
btw.
Apart from that: If you look at qobjectdefs.h you'll realize that emit
is just an empty macro, so you can leave it out anywhere where you're
concerned about pollution. Or you can #define QT_EMIT yourself.
> I'd like to keep some
> emit variant around as I wouldn't want to call everything sigFunction
> the way slotFunction seems to be the norm ;-)
No, slotFunction is not the norm. In fact I personally find this a
stupid way and Qt itself doesn't use the slot prefix either. A slot is a
member function just as any other member as well, except it can be
connected to a signal.
For the same reason I wouldn't add a sig prefix, I'd rather name the
method proberly so it is clear that this is a signal (like valueChanged,
textEdited and so on).
Andreas
--
[ signature omitted ]
Message 3 in thread
> I hope you realise this is the wrong place to send such stuff. Trolltech
> does have proper feedback channels for such wishes.
The feedback channels which I have found are qt-interest and that of
filing a bug report. I have done both. I felt qt-interest was the
closest thing to finding the Qt/Trolltech dev community (outside of
KDE of course). Could you be so kind as to tell me of any other proper
channels?
> > I'm only a minor adept at KDE but it seems here that everyone uses
> > Q_SIGNALS and friends where possible anyway.
> AFAIK that's not quite right, at least I personally use signals/slots
> most of the time, except in public API. Which is the kdelibs policy,
> btw.
My exposure is mainly TO the public API and as such I saw it as the
norm. If you're right, you're right.
> Apart from that: If you look at qobjectdefs.h you'll realize that emit
> is just an empty macro, so you can leave it out anywhere where you're
> concerned about pollution. Or you can #define QT_EMIT yourself.
Yes, I've seen qobjectdefs.h and it is mentioned in my bug report
(thought unfortunately absent from my first mail). A minor adept at
KDE should be able to grep the sources ;-)
Would using a personally #defined Q_EMIT in KDE code be a good idea? NO
Would it be a good one-liner for Trolltech to throw into qobjectdefs.h
(and perhaps get rid of ucky QT_NO_EMIT while we're at it)? I think so
> No, slotFunction is not the norm. In fact I personally find this a
> stupid way and Qt itself doesn't use the slot prefix either. A slot is a
> member function just as any other member as well, except it can be
> connected to a signal.
>
> For the same reason I wouldn't add a sig prefix, I'd rather name the
> method properly so it is clear that this is a signal (like valueChanged,
> textEdited and so on).
Yes, yes - some do, most don't. But much like some people prefer to
have a small suffix specifying the type of a member (_cz for char*
etc.) and some like a prefix to indicate a private member (e.g.,
m_foo), SOME like other specifiers. I like something to identify a
slot (when it's being called/connected such as using slotFunction) and
even the Qt devs like something to indicate a signal is being made
(using emit). These specifiers are invaluable for searching for
signals/slots in use.
Could the introduction of Q_SLOTS and no_keywords mean that Trolltech
thought of this? I believe so. Would the introduction of Q_EMIT
complete the circle? In my opinion, yes again.
This is all rather pointless if this thread is just to be used by us
for pointless argument (as the link in my first post turned into). I
posted here as it seemed a consensus was reached (by people I presumed
to be Trolltech employees). Let's hope another consensus is reached
for another 5/6 years ;-)
--
[ signature omitted ]
Message 4 in thread
On 02.07.07 00:58:17, Gavin Beatty wrote:
> >I hope you realise this is the wrong place to send such stuff. Trolltech
> >does have proper feedback channels for such wishes.
>
> The feedback channels which I have found are qt-interest and that of
> filing a bug report. I have done both. I felt qt-interest was the
> closest thing to finding the Qt/Trolltech dev community (outside of
> KDE of course). Could you be so kind as to tell me of any other proper
> channels?
I meant the bug-reporting channel, which is also correct for providing
wishes (AFAIK). There's also a feedback form on the trolltech webpage,
if I'm not mistaken. In particular this list is not the right place to
ask TT for new features.
> >Apart from that: If you look at qobjectdefs.h you'll realize that emit
> >is just an empty macro, so you can leave it out anywhere where you're
> >concerned about pollution. Or you can #define QT_EMIT yourself.
>
> Yes, I've seen qobjectdefs.h and it is mentioned in my bug report
> (thought unfortunately absent from my first mail). A minor adept at
> KDE should be able to grep the sources ;-)
> Would using a personally #defined Q_EMIT in KDE code be a good idea? NO
Call it K_EMIT ;) Seriously though, emit's are never in public headers
so you're safe unless you mix Qt code with code from a library that uses
emit functions or macro's itself in your implementations.
> Would it be a good one-liner for Trolltech to throw into qobjectdefs.h
> (and perhaps get rid of ucky QT_NO_EMIT while we're at it)? I think so
I hope you didn't misunderstand me: I was never arguing against having
Q_EMIT in Qt. I was merely stating that there are workarounds.
> even the Qt devs like something to indicate a signal is being made
> (using emit). These specifiers are invaluable for searching for
> signals/slots in use.
Huh? I didn't see any sig-prefix in Qt's public API.
Anyway, its up to the Trolls to decide wether its worth it or not.
Andreas
--
[ signature omitted ]
Message 5 in thread
> Huh? I didn't see any sig-prefix in Qt's public API.
No, no. I mean that EMITTING a signal is signposted (only as a
convention) with the "emit" keyword. If you need to doublecheck if
something IS a sig, even a lazy person such as I would use the header
;)
> Anyway, its up to the Trolls to decide wether its worth it or not.
True again. Let's see what the master says! :P
--
[ signature omitted ]
