[Kde-bindings] Qyoto: Delegates vs signals

Arno Rehn arno at arnorehn.de
Thu Sep 3 17:27:58 UTC 2009


On Thursday 03 September 2009 10:58:35 you wrote:
> On Wed, Sep 2, 2009 at 18:00, Arno Rehn <arno at arnorehn.de> wrote:
> > On Wednesday 02 September 2009 16:09:43 you wrote:
> > > Hi Arno Rehn
> > >
> > > I'm the one who made the following bug:
> > > https://bugs.kde.org/show_bug.cgi?id=205311
> > >
> > > I would really like to (or at least try to) dive a bit into the problem
> >
> > and
> >
> > > try to see if I can find something usable, but I'm not sure where to
> >
> > begin.
> >
> > > First off I'm a bit curious on why exactly do you actually need the
> >
> > ability
> >
> > > to overload signals?
> >
> > For the same reason you overload normal methods. And qt actually does
> > overload
> > signals in some of the classes. For example you have
> >
> > QComboBox::activated(int)
> > QComboBox::activated(QString)
> >
> > How should we deal with that?
>
> It might be me (or that particular case), but wouldn't some kind of
> EventArgs struct or something similar solve this. It could store both
> values and then the user could user select it with something like:
>
> delegate(EventArgs e) {
>    Consolse.WriteLine("{0} has the text {1}", e.Index, e.Text);
> }
>
> The problem I might see with that is that I can't see a function that
> passes both in the same time, so you would have to get the string via the
> int.
>
> I don't know if this is correctly observed, but if it is, shouldn't it be
> solvable? Or is there some aspects to it that I don't see?
Yes, that would be possible.. but there are two things I don't like about the 
idea...
1) it requires special casing because we can't dynamically get the index from 
the string. Overloading signals is kept to a minimum in Qt afaik, but still 
I'd like to avoid it any more special cases.

2) It uses EventArgs, one of the few really crap things in the framework. I 
don't know who designed it and why, but it just won't allow nice stuff like 
connecting a signal/event to an arbitrary method that wasn't originally 
intended to receive a signal (and there are quite a few use cases for that 
;)). I'd really like _NOT_ to resort to that ;)

> This would also bring the ability to send more data about the event, than
> just the index og the text, which might also make it more flexible in the
> long run.
>
> > We can only create one event with one specific name, so we either only
> > implement activated(int) or activated(QString) as an event.
> >
> > A solution to this would be to append the parameter type names to the
> > event name if it would be ambigious otherwise, but this would result in
> > something like
> >
> > combo.Activated_Int += /* ... */
> > combo.Activated_String += /* ... */
> >
> > which is really ugly.
>
> I agree, that's not desirable
>
> > Another approach would be to create methods like AddActivatedHandler()
> > which
> > take a delegate. Methods can be overloaded, so we can have
> > AddActivatedHandler(int) and AddActivatedHandler(string).
>
> That starts to look more like Java, but it's somewhat closer to what I
> would look for in an oo-language.
>
> > I recently got the idea of doing something like
> >
> > delegate SignalFunc<T>(T arg1);
> >
> > bool Connect<T>(SignalFunc<T> signal, SlotFunc<T> slot) {
> >        string signature = /* get signature of 'signal' */
> >        return Connect<T>(signal.Target.QObjectInstance, signature, slot);
> > }
> >
> > Connect<int>(Signals.Activated, this.Foo);
> >
> > where 'Signals' is a property which returns an instance of some special
> > class
> > exposing signals. That instance also has a reference to the QObject
> > instance
> > of which it exposes the signals.
> >  Each signal would then be a method with an empty body. It has an
> > attribute with the C++ method signature. With the Delegate.Target
> > property we can get the sender of the signal and with the attribute the
> > signature.
> > That would work, but it somehow breaks with the current design (where we
> > have
> > a special 'Emit' property to access and emit signals).
> >
> > If we implement it in a way like this, I'd completely revamp the whole
> > signal
> > stuff in Qyoto and maybe get rid of 'Emit' completely (in favour of
> > something
> > like Signals.Activated.Emit(5) and
> > Signals.Activated.Connect(myDelegate)).
>
> It's an improvement in my eyes, but still a bit strange for one used to the
> more common ways of C#, if I read it correctly it seems that it would
> enable autocompletion in IDEs, which I think most (all?) programmers would
> really like.
Yep, this is my favourite way by now.. But I think autocompletion would be 
enabled by all other (except the current) methods as well...

> [snip]
> > The tool for generating the sources is called 'kalyptus', but will
> > hopefully
> > be replaced by a generator plugin for the new smokegenerator in the near
> > future. Hacking kalyptus is quite a pain because it's all perl, but the
> > smokegenerator-based stuff should be more easy to read & hack.
>
> I sneaked into your blog, it looks very interesting, and I hope it'll be
> ready soon :)
Yes, it already generates the underlying smoke library quite fine and it's 
used in trunk by now. I hope I can start on the C# generator in a few 
days/weeks.

> I was wondering, what will you do with the documentation (in the long run)?
> Although it works fine finding things in the C++ documentation, I think a
> lot of people would like something more .net-like. Is there any plans for
> doing that, or?
Yep. The old kalyptus tool parsed C++ doxygen-style comments and converted 
them to C# inline xml documentation. That conversion produced faulty xml tags, 
but it proves that it's possible. The only problem is that Qt doesn't have the 
documentation in the headers, but in the cpp source files. But I think we can 
also come up with something that extracts the documentation from there.

-- 
Arno Rehn
arno at arnorehn.de




More information about the Kde-bindings mailing list