[Kde-java] Qt and KDE java package names

[Richard Dale]

On Monday 11 August 2003 12:25, Gert-Jan van der Heiden wrote:
> > Well, there are some disadvantages. Suppose you type a connect statement
> > like this:
> >
> > connect(mybutton, SIGNAL("clikked()"), mywidget,
> > SLOT("buttonPressed()"));
> >
> > ...and you misspell 'clicked()' as 'clikked()'. Then the QtJava runtime
> > will just assume that 'clikked()' is a java signal, rather than a C++ one
> > for QPushButton. You wouldn't get any sort of warning, but the slot
> > buttonPressed() would never get invoked.
>
> Can't that be traced by looking the method up via Java reflection (after
> SMOKE has told that the C++ signal doesn't exist) ?
>
> If clikked() isn't a Java method either, the reflection API will complain
> and throw an Exception, this could generate a warning.
>
> If clikked() does exist (mybutton is subclassed), the Java method will be
> invoked.
No, because signals aren't actual java methods in QtJava, and reflection 
wouldn't find them, they are just a name and a type signature, and a wrapper 
round an instance of a C++ JavaSignal (defined in JavaSlot.cpp/.h).

The way Ashley Winters implemented PerlQt depended on being able to 
dynamically add methods to an existing class. You can do that in perl and 
ruby, and signals in those bindings are actually methods, but that isn't 
possible in java.

-- Richard