[Kde-java] Signals and Slots implemented in Java

[Richard Dale]

On Tuesday 21 October 2003 08:58, Marco Ladermann wrote:
> Am Montag, 20. Oktober 2003 17:10 schrieb Marco Ladermann:
> > This seems to be a good idea: have a interface for all signals (and
> > another one for the slots) build by classname and appended "Signals"
> > ("Slots"). But even if the lookup in the inheritance hierachy is simple,
> > the user has still to know in which super class the interface is defined
> > to call the appropriate signal method. The Proxy must be casted to this
> > interface. What about also requiring that the super signal interface must
> > be extended by the current class signal interface?
>
> One problem here: If one defines no new signals in a class, an extended
> version of this class with signals must extend the grandparents signal
> interface. Arrg.
>
> But we could leave out the classname from the signal interface like this:
>
> public class MyWidget extends QSuper {
>   public interface Signals extends QSuper.Signals {
>     ...
>   }
> }
>
> the above mentioned problem should then be solved.
Hmm, maybe using 'extends' is more trouble than it's worth and better to leave 
it to the user to cast to a superclass's Signals interface. I think nearly 
always you will want to emit a MyWidget signal thats in MyWidgetSignals, 
rather than a superclass's interface.

> One further problem with the extends approach might be that the private
> signals of a super class are imported in the current class, but I think
> this can be cecked in the "connect" or "emit".
Yes, and only connecting protected signals in the context of a subclass could 
be checked at runtime too perhaps.

-- Richard