[Kde-java] Signals and Slots implemented in Java

[Richard Dale]

On Sunday 12 October 2003 18:43, Marco Ladermann wrote:
> On Friday 10 October 2003 17:16, Richard Dale wrote:
> > You need to be able to
> > connect signals to signals too.
>
> Changed the base class to QObject and implemented connection of Signals to
> SIgnals (via proxies of course).
>
>   MyWidget a, b;
>   a.connect(MySignal.class, b, AnotherSignal.class);
I'm afraid I just don't find this syntax as clear as the original C++ style 
with SLOT() and SIGNAL() macros. It means you have to go and look at the 
definitions of MySignal and AnotherSignal (or AnotherSlot) to see what's 
going on, and with a large api that might take some tracking down. What if 
you are trying to connect to a slot which is inherited from a superclass - 
you have to get from the name of the class representing the slot to finding 
the actual implementation as a nested class inside an inherited widget class. 
How would the classnames for the slot and signal wrappers be autogenerated - 
say two slot methods were called foobar(), one took an int and one a string - 
what would the class be called?

It seems to me that you've made life more convenient for the java compiler at 
the expense of the java programmer. But then I'm biased, I generally prefer 
dynamic programming approaches, so strings of 'code' as the slot and signal 
strings being evaluated at runtime (and lack of static type safety) don't 
bother me in the slightest..

I like the idea of emit() using proxies, but I don't think you should have to 
pass in a signal class like this:

    protected Signal emit(Class signal)
    {
        // find signal proxy
        Signal sigProxy = (Signal) signalProxies.get(signal);

        if (sigProxy == null)
        {
            // check the signal and get signal method
            Method signalMethod = checkSignal(signal);
...

Instead:

    protected Proxy emit()
    {
	String signalInterfaceName = this.getClass().getName() + "Signals";
	Object signalInterface = Class.forName(signalInterfaceName);

            sigProxy =
                (Signal) Proxy.newProxyInstance(
                    signalInterface.getClassLoader(),
                    new Class[] { signalInterface },
                    new QObject.SignalHandler(
                        this
                    )
                );

Then as an enhancement it should walk up the inheritance heirarachy, getting 
any <classname>Signals interface it finds in the superclasses, and adding 
them to the array passed to the Proxy constructor. 

I've attached the current list of classes in the Smoke runtime as they would 
appear in java, eg qt.QWidget or kde.KMainWindow. There are 383 kde classes, 
379 qt classes, 13 kparts classes and 31 kio classes. In addition the current 
kde java package has 202 <classname>Signals.java interfaces, giving a total 
of nearly 600 classes/interfaces in the main kde package.  If every signal 
and slot were to become a class I think it would just get out of hand, even 
if they were nested classes.

Perhaps the best thing would be to try and generate a 'prototype' api and see 
what it looks like - I might well be wrong - it's happened before :). It's 
just my feeling that what looks good with small test cases, wouldn't scale 
and be so tidy with the enormous Qt and KDE packages.

-- Richard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: classes.java
Type: text/x-java
Size: 13232 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-java/attachments/20031020/854a1151/classes.bin