[cfe-dev] Proposal: parsing Qt signals/slots with attributes

[Ahmed Charles]

I prefer the design of the attributes with namespaces (potentially added to
03 as an extension). It seems like what attributes are meant to solve. And
reclaiming signals and slots (along with foreach/emit/etc.) Isn't really
possibly unless all compiles have them be context sensitive keywords, which
is ultimately unlikely.

And I once spent hours changing a codebase from the lowercase version to the
upper case macros only to realize that foreach != for_each... Needless to
say, I didn't switch back!
------------------------------
From: Douglas Gregor
Sent: 9/28/2011 4:42 PM
To: David Blaikie
Cc: Clang Dev List
Subject: Re: [cfe-dev] Proposal: parsing Qt signals/slots with attributes


On Sep 28, 2011, at 12:12 PM, David Blaikie wrote:

On Wed, Sep 28, 2011 at 10:50 AM, Douglas Gregor <dgregor at apple.com> wrote:

>
> On Sep 20, 2011, at 1:10 AM, erikjv wrote:
>
> > Hello,
> >
> > I would like to add support for recognising Qt's signal/slot mechanism to
> clang by using attributes. For that, I have a proposal for a few small
> changes to the clang parser. These changes use the attributes to mark AST
> nodes as signal/slot/invokable, and expose those attributes through
> libclang.
> >
> > A bit of background: if you are more familiar with Objective-C, then the
> signal/slot mechanism works nearly exactly the same as Cocoa's
> IBAction/IBOutlet: it uses a meta-type system to invoke the methods, or let
> slots connected to a signal know that the signal was emitted. Qt's meta-type
> system also allows for "invokable methods", which can be called/invoked
> without being tagged as slot.
> >
> > Example:
> >
> > class Test {
> > public:
> >     Q_INVOKABLE void invokableA();
> >
> > public slots:
> >     void slotA();
> >     void inlineSlotB() {}
> >
> > signals:
> >     void signalC();
> >
> > private:
> >     Q_SIGNAL void signalD(), signalE();
> >     Q_SLOT void slotF(), slotG();
> >     void not_a_slot_or_slot();
> >     Q_SLOT void inlineSlotH() {}
> > };
> >
> > (To be used properly with Qt, the class would also have to inherit from
> QObject, and have the Q_OBJECT macro right after the opening brace.)
> >
> > Taking a leaf from Cocoa's book, we can use the pre-processor to inject:
> >
> > #define signals protected __attribute__((q_signal))
> > #define slots __attribute__((q_slot))
>
> Alright, since there haven't been enough crazy ideas today… I think we
> should consider defining 'signals'  and 'slots'  as context-sensitive
> keywords, rather than handling these as attributes on the access specifier.
> The grammar is fairly simple, and one need only look ahead a single token
> (to the ':') to determine whether we have the signals or slots keyword (vs.
> using it as an identifier). It shouldn't be much more work than threading
> attributes through the access specifiers like you've already done.
>

Out of curiosity, how would this satisfy criteria (4) of the clang language
extension guidelines (
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-July/016275.html ) - would
this be practically standardizable? (it certainly fulfills several, perhaps
all, of the other criteria - existing community, etc)


Sadly, it would not satisfy criteria (4), and we would have to live with
that, because it's clearly not something that the committee would ever
standardize. The Qt developers of old did us all a grave injustice in the
first place by #define'ing lowercased identifiers and then having the gall
to become wildly popular, so we're fairly stuck now: either we do some
attribute trickery and keep on defining "signals" and "slots", or we
introduce a not-likely-to-ever-be-standardized feature to make existing Qt
code work better and reclaim "signals" and "slots" in the process.

Is it possible to support C++11 attributes (& namespaced attributes) as an
extension in C++03, or does that break other things? Seems a pity to further
extend an extension that's been superseded by a standard feature.


We could probably support C++11 attributes in C++03; I don't think it
actually breaks anything.

- Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110928/3892c66d/attachment.html>