[Kde-java] Signals and Slots implemented in Java

[Marco Ladermann]

On Friday 10 October 2003 17:16, Richard Dale wrote:
> On Thursday 09 October 2003 19:47, Marco Ladermann wrote:
> > but maybe someone finds them interesting anyway.
>
> Yes, I found it interesting. But QtJava has to work with existing C++
> slots/signals as well as java ones, and users wouldn't expect a different
> syntax for C++ vs. java slots - I'm not sure if it's possible to make C++
> look like your java approach.

Aren't the C++ Slots simply methods? I thought one could extract the C++ 
signals and define them as Signal extending interfaces and the Slot objects 
can be generated as proposed with a call to the "real" slot method. This 
would bypass the Qt mechanism, but can this do any harm? I don't know.

>
> > Here is the outcome of my meditation:
> >
> > 1) Signals can be represented by interfaces extending a tagging interface
> > (Signal) and declaring exaclty one method: the signal itself.
>
> I don't like the idea of lots of classes much, I'd rather have all the
> signal type signatures in a single interface.

Yes, that would be much better. But I have no idea how to refer to a decided 
signal in the connect, without having again some identifing string. 

>
> > 2) Slots are objects of an anonymous class extending a tagging class
> > (Slot) that define a single method: the slot.
>
> This looks quite nice, but you are defining the slot as an isolated thing.
> It isn't a void method of MyWidget or whatever, and so it won't have access
> to any of the instance variables etc in the MyWidget environment.

No. The new Slot class is defined locally in the MyWidget environment and 
*not* static, so it has access to all instance variables and methods! See the 
example in my original mail.

> > 3) Signals and slots are connected by source object, signal class and
> > target slot object.
>
> I might have missed something, but I couldn't see the source object being
> used. It looks to me as though the emit() could be called from anywhere,
> and not associated with a specific source object.

No again. The emit method is a protected instance method that access a 
signal-slot table per instance.

> You need to be able to
> connect signals to signals too.

Upps. You're right. Forgot that. I'll meditate on that...

> I like this idea of emit() returning a Proxy, and the signal being a call
> on that. But I would prefer emit() to be an instance method of QObject and
> subclasses, which would return a Proxy that you could cast to the Signals
> interface you wanted to use:
>
> Eg:
> (MyWidgetSignals emit()).clicked(5);

I should have called the root class QObject and not Qt, right? Then the 
implementation does exactly that. In the object where you want to emit a 
signal, call:
	((MyWidgetSignal) emit(MyWidgetSignal.class)).clicked(5);

The class parameter is needed for the proxy to distinguish the different 
signals.

> I suppose it comes down to deciding whether we're trying to create a new
> java api as 'javalike' as possible, or to make java code look as much like
> the original Qt C++ style as possible.

Both approaches have benefits and drawbacks. Personally I'm not settled. In 
some moments I have thought about a third alternative, using a preprocessor 
like moc to have all freedom in wrapping the c++ instances.

> I think one of the big problems with Swing is that you have to keep
> defining loads of clunky little event listeners classes all over the place,
> whereas you don't need to do that with the standard Qt approach. Java would
> be better off with delegates - but that's just my opinion. Lots of small
> classes with a single method to emulate delegates would probably result in
> cluttered looking code.

After years of java programming, I have learned to live with listeners. But of 
course, beauty is always an issue!

Thanks for your comments, I'll try to improve my prototype (until the point 
where it can send mail ;)

Marco
--