Qt-jambi-interest Archive, April 2007
QSignalEmitter.AbstractSignal.connect etc
Message 1 in thread
Hi,
I came on couple of questions while playing with jambi beta:
1) why not connect a signal only by method name (it think it will be enough
in 95% use cases), and if it could not be disambiguated throw some
exception and provide also something like connect( Object o, String
methodName, Class... signature) for more "precise" usage? It's certainly
more "user friendly" and less error prone to type for example:
connect( this, "slot")
or:
connect( this, "slot", int.class, List<A>.class )
then:
connect( this, "slot(int, java.util.List<A>)" )
2) it looks like the list off java made connections is stored on java side,
so why not enable usage of some java-like callbacks? I mean allow objects
implementing given interfaces (e.g Callable0, Callable1<A> etc) to be
directly connected to signals? Sometimes it's more convenient and it's
something java users are probably used to.
eg: clicked.connect( new Callable0() { public void call() {
System.out.println("clicked); } } );
3) are you planning to implement Compatarable interface in objects providing
operator_less() and friends? are operators part of java api or are they just
for internal usage? and QTextStream? is it part of api?
operator_shift_right and operator_shift_left dont't look too good :)
Thanks
Jakub
Message 2 in thread
Hi, Jakub.
Jakub Dvorak wrote:
>methodName, Class... signature) for more "precise" usage? It's certainly
>more "user friendly" and less error prone to type for example:
>connect( this, "slot")
>or:
>connect( this, "slot", int.class, List<A>.class )
>then:
>connect( this, "slot(int, java.util.List<A>)" )
>
>
Thanks for these suggestions. There's always a trade off between having
an API which is convenient and an API which is consistent, easy to learn
and easy to maintain, but I will register these suggested overloads and
we will definitely consider adding them, because they seem very convenient.
>so why not enable usage of some java-like callbacks? I mean allow objects
>implementing given interfaces (e.g Callable0, Callable1<A> etc) to be
>directly connected to signals? Sometimes it's more convenient and it's
>something java users are probably used to.
>eg: clicked.connect( new Callable0() { public void call() {
>System.out.println("clicked); } } );
>
>
We have a task for this, but it currently has no precise schedule. If
several people voice their interest in it, we will take that into
consideration in the scheduling.
>3) are you planning to implement Compatarable interface in objects providing
>operator_less() and friends? are operators part of java api or are they just
>for internal usage? and QTextStream? is it part of api?
>operator_shift_right and operator_shift_left dont't look too good :)
>
>
Yes, I agree :-) The methods are part of the API, but the naming here is
awkward due to the generator's inability to decide the context of the
operator overloads, and thus, inability to sensibly name these methods
automatically.
A lot of work has gone into cleaning this up for the upcoming beta
release, so most cases of operator_foo_bar() patterns will be gone from
the API.
For the text/data stream, we will now use a readFoo/writeFoo pattern for
input and output to the streams, and we will implement the Comparable
interface for all classes where this is possible. A few more classes
will also get a reimplementation of the equals() method.
Thanks for you feedback!
-- Eskil
Message 3 in thread
Thanks for your answers.
I'm looking forward to next betas :)
Jakub
Eskil Abrahamsen Blomfeldt wrote:
> Hi, Jakub.
>
> Jakub Dvorak wrote:
>
>>methodName, Class... signature) for more "precise" usage? It's certainly
>>more "user friendly" and less error prone to type for example:
>>connect( this, "slot")
>>or:
>>connect( this, "slot", int.class, List<A>.class )
>>then:
>>connect( this, "slot(int, java.util.List<A>)" )
>>
>>
>
> Thanks for these suggestions. There's always a trade off between having
> an API which is convenient and an API which is consistent, easy to learn
> and easy to maintain, but I will register these suggested overloads and
> we will definitely consider adding them, because they seem very
> convenient.
>
>>so why not enable usage of some java-like callbacks? I mean allow objects
>>implementing given interfaces (e.g Callable0, Callable1<A> etc) to be
>>directly connected to signals? Sometimes it's more convenient and it's
>>something java users are probably used to.
>>eg: clicked.connect( new Callable0() { public void call() {
>>System.out.println("clicked); } } );
>>
>>
>
>
> We have a task for this, but it currently has no precise schedule. If
> several people voice their interest in it, we will take that into
> consideration in the scheduling.
>
>>3) are you planning to implement Compatarable interface in objects
>>providing operator_less() and friends? are operators part of java api or
>>are they just for internal usage? and QTextStream? is it part of api?
>>operator_shift_right and operator_shift_left dont't look too good :)
>>
>>
>
> Yes, I agree :-) The methods are part of the API, but the naming here is
> awkward due to the generator's inability to decide the context of the
> operator overloads, and thus, inability to sensibly name these methods
> automatically.
>
> A lot of work has gone into cleaning this up for the upcoming beta
> release, so most cases of operator_foo_bar() patterns will be gone from
> the API.
>
> For the text/data stream, we will now use a readFoo/writeFoo pattern for
> input and output to the streams, and we will implement the Comparable
> interface for all classes where this is possible. A few more classes
> will also get a reimplementation of the equals() method.
>
> Thanks for you feedback!
>
> -- Eskil
Message 4 in thread
>> so why not enable usage of some java-like callbacks? I mean allow
>> objects
>> implementing given interfaces (e.g Callable0, Callable1<A> etc) to be
>> directly connected to signals? Sometimes it's more convenient and it's
>> something java users are probably used to.
>> eg: clicked.connect( new Callable0() { public void call() {
>> System.out.println("clicked); } } );
>>
>>
>
>
> We have a task for this, but it currently has no precise schedule. If
> several people voice their interest in it, we will take that into
> consideration in the scheduling.
I sign up on this poll!
Helge Fredriksen
Message 5 in thread
Eskil Abrahamsen Blomfeldt wrote:
> Hi, Jakub.
>
> We have a task for this, but it currently has no precise schedule. If
> several people voice their interest in it, we will take that into
> consideration in the scheduling.
Since voice seem to matter, I'll also raise my hand for this one.
Callbacks using interfaces is something that I *really* want in Qt/Jambi.
For one, I think it's a cleaner approach. Secondly, any time you have
method names in strings, you risk the chance of refactoring problems.
Message 6 in thread
Just my two cents on the first two suggestions :
> 1) why not connect a signal only by method name (it think it
> will be enough
> in 95% use cases), and if it could not be disambiguated throw some
> exception and provide also something like connect( Object o, String
> methodName, Class... signature) for more "precise" usage?
> It's certainly
> more "user friendly" and less error prone to type for example:
> connect( this, "slot")
> or:
> connect( this, "slot", int.class, List<A>.class )
> then:
> connect( this, "slot(int, java.util.List<A>)" )
>
Yes that would make good sense, especially since the current connect syntax is merely a reflection of the C++ syntax, which is
itself a hack to work around the limitations of the language. So since the connection syntax already had to be adapted for Java
(with the signal objects, etc.), why not go all the way and benefit from a better syntax like the one proposed above.
The only issue is the variable number of arguments for connect. I don't know java enough to know if it supports vararg methods, but
that could be a solution, otherwise a series of overloads with e.g. 0 to 4 arguments, plus a generic one accepting a list of Class
objects.
> 2) it looks like the list off java made connections is stored
> on java side,
> so why not enable usage of some java-like callbacks? I mean
> allow objects
> implementing given interfaces (e.g Callable0, Callable1<A> etc) to be
> directly connected to signals? Sometimes it's more convenient and it's
> something java users are probably used to.
> eg: clicked.connect( new Callable0() { public void call() {
> System.out.println("clicked); } } );
>
Hmm, I'm not convinced by this one on the other hand.
First because this is a drift back in the direction of Swing, which is the very same pattern many people are complaining about, and
which is incidently making code horrible to read afterwards.
Second is that it kind of breaks the concept of signal/slots connections itself, ie. you want to connect to an interface and not a
method. Fine, but that means breaking compatibility with C++ and introducing a conceptual difference between the two, which I
believe Trolltech should stay away at all costs.
And finally, I'm mostly questionning the real point of it : I mean, what is that going to give you besides the ability of printing
out "clicked" or "hello world" ? In general, slots are part of complex classes with multiple members, and multiple slots actually,
and these classes contain lots of code, more than you would ever want to put together in an anonymous class if you have any mercy
for the readers of the code later on. So as far as I can remember (and that would be 3 years of Qt programming full-time on customer
projects), I can't think of one justified use of the pattern above, especially in Java where it's so easy to define a new class.
Best regards,
Romain Pokrzywka
Software Engineer - Qt consultant
Klaralvdalens Datakonsult AB
www.kdab.net
> -----Original Message-----
> From: Jakub Dvorak [mailto:bazin@xxxxxxxx]
> Sent: Tuesday, April 03, 2007 5:13 PM
> To: qt-jambi-interest@xxxxxxxxxxxxx
> Subject: QSignalEmitter.AbstractSignal.connect etc
>
> Hi,
> I came on couple of questions while playing with jambi beta:
>
> 1) why not connect a signal only by method name (it think it
> will be enough
> in 95% use cases), and if it could not be disambiguated throw some
> exception and provide also something like connect( Object o, String
> methodName, Class... signature) for more "precise" usage?
> It's certainly
> more "user friendly" and less error prone to type for example:
> connect( this, "slot")
> or:
> connect( this, "slot", int.class, List<A>.class )
> then:
> connect( this, "slot(int, java.util.List<A>)" )
>
> 2) it looks like the list off java made connections is stored
> on java side,
> so why not enable usage of some java-like callbacks? I mean
> allow objects
> implementing given interfaces (e.g Callable0, Callable1<A> etc) to be
> directly connected to signals? Sometimes it's more convenient and it's
> something java users are probably used to.
> eg: clicked.connect( new Callable0() { public void call() {
> System.out.println("clicked); } } );
>
> 3) are you planning to implement Compatarable interface in
> objects providing
> operator_less() and friends? are operators part of java api
> or are they just
> for internal usage? and QTextStream? is it part of api?
> operator_shift_right and operator_shift_left dont't look too good :)
>
> Thanks
> Jakub
>
Message 7 in thread
Hi, Romain.
Romain Pokrzywka wrote:
>The only issue is the variable number of arguments for connect. I don't know java enough to know if it supports vararg methods, but
>that could be a solution, otherwise a series of overloads with e.g. 0 to 4 arguments, plus a generic one accepting a list of Class
>objects.
>
>
Starting with Java 1.5 (which is required for Qt Jambi) it does in fact
support varargs, and it would actually be quite simple to implement this
using the existing mechanism.
>Hmm, I'm not convinced by this one on the other hand.
>First because this is a drift back in the direction of Swing, which is the very same pattern many people are complaining about, and
>which is incidently making code horrible to read afterwards.
>Second is that it kind of breaks the concept of signal/slots connections itself, ie. you want to connect to an interface and not a
>method. Fine, but that means breaking compatibility with C++ and introducing a conceptual difference between the two, which I
>believe Trolltech should stay away at all costs.
>And finally, I'm mostly questionning the real point of it : I mean, what is that going to give you besides the ability of printing
>out "clicked" or "hello world" ? In general, slots are part of complex classes with multiple members, and multiple slots actually,
>and these classes contain lots of code, more than you would ever want to put together in an anonymous class if you have any mercy
>for the readers of the code later on. So as far as I can remember (and that would be 3 years of Qt programming full-time on customer
>projects), I can't think of one justified use of the pattern above, especially in Java where it's so easy to define a new class.
>
Thank you for your comments. I tend to agree with you on this. In most
cases where I implement listeners using anonymous classes, they will
only serve to delegate the method call into another method which is more
aptly named and fits better in the context and structure of the
application. So in my case, the Listener pattern exclusively hurts the
readability of the code and adds a lot of syntax with very little actual
meaning.
Can anyone think of specific use cases where a Listener pattern
implemented on top of signals and slots would be useful? Or is this
request primarily based on the fact that more Java developers are
familiar with that pattern and tend to structure their code around it?
-- Eskil
Message 8 in thread
Hi,
I just realized that there's a problem in connecting like this:
specifying connection type.
So I've got another proposition :)
simple connection (no overloads):
connect( SLOT(object, "slot") );
"advanced" connection:
connect( SLOT(object, "slot", int.class, List.class), Qt.ConnectionType.xy )
where SLOT is is final protected method in QSignalEmitter returning
something like
class Slot {
public Object object;
public Method method;
}
Jakub
> Hi,
> I came on couple of questions while playing with jambi beta:
>
> 1) why not connect a signal only by method name (it think it will be
> enough in 95% use cases), and if it could not be disambiguated throw some
> exception and provide also something like connect( Object o, String
> methodName, Class... signature) for more "precise" usage? It's certainly
> more "user friendly" and less error prone to type for example:
> connect( this, "slot")
> or:
> connect( this, "slot", int.class, List<A>.class )
> then:
> connect( this, "slot(int, java.util.List<A>)" )
>
> 2) it looks like the list off java made connections is stored on java
> side, so why not enable usage of some java-like callbacks? I mean allow
> objects implementing given interfaces (e.g Callable0, Callable1<A> etc) to
> be directly connected to signals? Sometimes it's more convenient and it's
> something java users are probably used to.
> eg: clicked.connect( new Callable0() { public void call() {
> System.out.println("clicked); } } );
>
> 3) are you planning to implement Compatarable interface in objects
> providing operator_less() and friends? are operators part of java api or
> are they just for internal usage? and QTextStream? is it part of api?
> operator_shift_right and operator_shift_left dont't look too good :)
>
> Thanks
> Jakub
Message 9 in thread
And if (VERY SIMPLIFIED !!!)
thy hypothetical class
class Slot {
public Object object;
public Method method;
}
will not be final we could get callbacks for free (even if maybe not
officially supperted :) )
with something like this:
abstract class Callback extends Slot
{
Callback()
{
object = this;
method = getClass.getMethod("action", new Class[0] );
}
abstract void action();
}
(it's not very clean and I'm not 100% it will work)
in fact callbacks are possible even now
(but they're not very convenient) like this:
signal.connect(
new Object () {
public void slot() { System.out.print( "slot called" ); } },
"slot()" );
Jakub
> Hi,
> I just realized that there's a problem in connecting like this:
> specifying connection type.
>
> So I've got another proposition :)
>
> simple connection (no overloads):
> connect( SLOT(object, "slot") );
>
> "advanced" connection:
> connect( SLOT(object, "slot", int.class, List.class), Qt.ConnectionType.xy
> )
>
> where SLOT is is final protected method in QSignalEmitter returning
> something like
> class Slot {
> public Object object;
> public Method method;
> }
>
> Jakub
>
>> Hi,
>> I came on couple of questions while playing with jambi beta:
>>
>> 1) why not connect a signal only by method name (it think it will be
>> enough in 95% use cases), and if it could not be disambiguated throw some
>> exception and provide also something like connect( Object o, String
>> methodName, Class... signature) for more "precise" usage? It's certainly
>> more "user friendly" and less error prone to type for example:
>> connect( this, "slot")
>> or:
>> connect( this, "slot", int.class, List<A>.class )
>> then:
>> connect( this, "slot(int, java.util.List<A>)" )
>>
>> 2) it looks like the list off java made connections is stored on java
>> side, so why not enable usage of some java-like callbacks? I mean allow
>> objects implementing given interfaces (e.g Callable0, Callable1<A> etc)
>> to be directly connected to signals? Sometimes it's more convenient and
>> it's something java users are probably used to.
>> eg: clicked.connect( new Callable0() { public void call() {
>> System.out.println("clicked); } } );
>>
>> 3) are you planning to implement Compatarable interface in objects
>> providing operator_less() and friends? are operators part of java api or
>> are they just for internal usage? and QTextStream? is it part of api?
>> operator_shift_right and operator_shift_left dont't look too good :)
>>
>> Thanks
>> Jakub
