Using something like SIGNAL and SLOT is conceptually and syntactically much cleaner than templates, and that's what a lot of (most?) people look for. glib just uses a string for their connections, as in
self.connect('message', self.on_message)
which I consider to be very pythonic. Both pygtk and pyqt offer quite a lot of improvements over their c/c++ orignals, and I think these improvements should each be considered. Leaving SIGNAL in as an options sounds like a good comprimise.
On 2/19/06, David Boddie <[EMAIL PROTECTED]> wrote:
On Sun Feb 19 15:30:53, Giovanni Bajo wrote:
> Phil Thompson <phil at riverbankcomputing.co.uk> wrote:
>
> > (In fact I don't see why Qt still needs SIGNAL() and SLOT() - maybe
> > the speed penalty of the alternative is more an issue at the C++
> > level.)
>
> Nah. There's boost::signal, which is a full-blown signal/slot implementation
> which works totally at compile time and has zero overhead. In fact, there is
> technically *nothing* that moc does which cannot be done with C++ and some
> advanced tecniques. But Trolltech seems to like the separate compilation
> step more than templates.
Indeed, but see these documents for a more complete discussion:
http://doc.trolltech.com/4.1/templates.html
http://scottcollins.net/articles/a-deeper-look-at-signals-and-slots.html
I think one of the motivations for using a preprocessor-based approach is
the continued lack of support for certain C++ advanced techniques with some
compilers. Nonetheless, the first document aims to provide other
justifications for using moc.
> > So, what so you think? Is dropping them to much of a cultural change?
> > (Of course they could also be made optional.)
>
> I'm fine with dropping them as long as they're optional.
I also think it's fine to make them optional. Some people might appreciate
the explicit nature of SIGNAL and SLOT in their code.
I imagine it's still possible to distinguish between signals and slots with
this method, and continue to allow signals to be connected to signals without
ambiguity.
David
_______________________________________________
PyKDE mailing list [email protected]
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
--
Patrick Kidd Stinson
http://pkaudio.sourceforge.net/
http://pksampler.sourceforge.net/
_______________________________________________ PyKDE mailing list [email protected] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
