[Kde-bindings] ruby bindings

[Richard Dale]

On Thursday 03 July 2003 00:32, Ashley Winters wrote:
> --- Richard Dale <Richard_Dale at tipitina.demon.co.uk> wrote:
> > I don't like scripting languages to have to use C++ type signatures
> > for
> > connecting signals and slots, I think they should be hidden from a
> > prototyping language like perl or ruby.
> >
> > This:
> > Qt::Object::connect(fontComboBox, SIGNAL "activated(string)",
> > textEdit, SLOT
> > "setFocus()");
> >
> > Rather than this:
> > Qt::Object::connect(fontComboBox, SIGNAL "activated(const QString&)",
> >
> > textEdit, SLOT "setFocus()");
> >
> > ..or maybe not. I assume PerlQt users haven't complained so perhaps
> > it doesn't
> > matter.
>
> I complain. Oh, how I complain. WHY didn't QSA provide a
> language-neutral signal/slot naming format for us to steal? *cry*
>
> I cannot begin to describe how disappointed I am in QSA as a language
> binding. It's not. Of course, it never claimed to be. I only hoped.
I was meaning to have a look at it to see what they'd done for QSA. I agree it 
would be nice to have a standing scripting naming format, oh well..

If you're scripting an existing C++ application with QSA it might be more 
acceptable to see C++ type signatures in the script slots/signals. But with 
the other bindings like perl or ruby where you're writing complete apps, the 
intention is to have a self contained 'world' that looks native to the target 
language, and no nasty C++ syntax exposed anywhere.

Java has a type system like a simplified C++, so I don't think qtjava could 
use the same scripting language-neutral types in its signals/slots.

I adapted the Qt Designer cppeditor plugin for java as 'javaeditor' to see 
what could be customised via a Designer plugin. Unfortunately I found it 
isn't possible to customise the lists of signal/slot types displayed to show 
java, although I did manage to 'javatize' the code completion/syntax 
highlighting and a few other things ok.

> If I had my preference, signal/slot syntax in PerlQt would be
> different. I've contemplated this:
>
> fontComboBox CONNECT -activated => textEdit SLOT -setFocus;
>
> Sadly, it wouldn't work for scalars, only for declared attribute
> objects. Perhaps I'll add it anyways, just for kicks.
>
> The main problem would be the damned overloaded signal/slot names, and
> having to guess which prototype to use. How often would we need to
> handle it? Would it be better to come up with an inter-language/class
> decoration? -resizeInt vs. -resizeRect or something?.
That looks like Objective-C selectors to me there. You can't overload method 
names in objc, so I had to generate this sort of thing for the qtobjc 
bindings:
[foobar resizeInt: 5] 
or
[foobar resizeRect: &myrect]

It stripped the 'Q' off classes like QWidget to give resizeWidget, and not 
resizeQWidget, as it looks better.

> I wouldn't suggest slot renaming. It's unfortunate.
Is that not possible with the way you did slots/signals in Qt.xs, I'm still 
trying to puzzle all that stuff out..

> As far as guessing, here's where I would draw the line:
>
> The signal has prototypes, and the slot has prototypes. Find the
> largest number of slot arguments that has a corresponding signal with
> an identical prototype, then select the signal with the shortest number
> of arguments among those that match. If this system ends up with
> multiple applicable matches, like signal(int) => slot(int) or
> signal(double) => slot(double), it's ambiguous. You may either rand(),
> use a precedence order, or raise an error.
If more than one possible C++ signal/slot type matches a type like a java 
String (eg 'const QString&' and 'QString' are both java.lang.Strings) in a 
connect statement, it uses QMetaObject::findSignal() on the instance emitting 
the signal to disambiguate the alternatives. 

-- Richard