[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bindings
Subject:    [Kde-bindings] Signal/slot method signature constants
From:       Ashley Winters <jahqueel () yahoo ! com>
Date:       2006-07-30 12:12:10
Message-ID: 20060730121210.42616.qmail () web50904 ! mail ! yahoo ! com
[Download RAW message or body]

I've had on my TODO list for a long time eliminating the C++ function
signature requirement from signals/slots. I dislike the loss of
abstraction (which is especially amusing in Jambi).

So, my current thought is to create constants representing the
signals/slots we want to use. The constant would be the name of the
method, with an InitialCap. For instance, in Perl:

Qt::Object::connect($button, Qt::AbstractButton::Clicked, $app,
Qt::CoreApplication::Quit);
# or...
Qt::Object::connect($button, $button->Clicked, $app, $app->Quit);
# or...
Qt::Object::connect($button->Clicked => $app->Quit);
# or, if we wanted to steal a page from .NET
$button->Clicked += $app->Quit;
# or, with more seriousness, we could invent the "on" prefix
$button->onClicked($app->Quit);

The constants themselves would be the actual C++ method signature. With
some voodoo, calling it as a method ($button->Clicked) would return an
object which Qt::Object::connect() could especially recognize as
containing both a QObject and a Member signature.

If there is an enum constant of the same name, it would always take
precedence (since there's always the "proper" way to specify member
signatures). The constants would simply be the signal/slot name with an
initial cap -- from the most derived class, when called as a method. If
there are multiple signatures available, we should pick the most
useful&featureful as "the" signature corresponding to the constant.

To avoid having to specify the C++ signature when declaring
signals/slots in the target language, I think we should use
compatibility declarations. We would use another method's signature as
the signature we will be "compatible" with, in the rare case where
pre-declared compatibility matters. Really, though, any connect() which
happens in script-land could theoretically generate the proper method
based on the C++ method's signature at runtime. It's mainly connect()
calls occuring in C++-land that we need the compatibility for.

# declare a signal which could be connected to
QWidget::setVisible(bool)
sub mySignal : signal connects(Qt::Widget::SetVisible);

That declaration also creates the __PACKAGE__::MySignal constant which
corresponds to "1mySignal(bool)". The actual name connects() is
entirely speculative.

I used to think there was a reason this wouldn't work, but I've since
forgotten what it was. Can anyone discover such a reason independently?
Anything here seem especially appealing across languages?

- Ashley Winters

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
_______________________________________________
Kde-bindings mailing list
Kde-bindings@kde.org
https://mail.kde.org/mailman/listinfo/kde-bindings
[prev in list] [next in list] [prev in thread] [next in thread]