Trolltech Home | Qt-jambi-interest Home | Recent Threads | All Threads | Author | Date
All threads index page 1

Qt-jambi-interest Archive, October 2006
Signal/slot suggestion


Message 1 in thread

One thing I see that would be really neat is direct initialization of 
objects when signals are emitted. That is, the possibility to put
an Object of same type that is emitted in the connect statement.

Like this

protected Boolean myState;

mySignalSender.stateEmitter.connect(this, myState);


When the mySignalSender instance sends a signal, the myState variable 
automatically gets updated without the need of going through a routine. 
This could work similar with other objects. This also works better with 
refactoring than the string method approach. The objects beeing 
initialized through this way would need to have a constructor that is 
free of arguments of course, and one could even then do the coding in 
the constructor that is handeled in the method passed as string in the 
current approach.

Just some wild thoughts...

Helge Fredriksen


Message 2 in thread

I think you made a thinko, a Boolean is immutable so referencing the object 
will not help since it would never change.

On Tuesday 17 October 2006 10:47, Helge Fredriksen wrote:
> One thing I see that would be really neat is direct initialization of
> objects when signals are emitted. That is, the possibility to put
> an Object of same type that is emitted in the connect statement.
>
> Like this
>
> protected Boolean myState;
>
> mySignalSender.stateEmitter.connect(this, myState);
>
> When the mySignalSender instance sends a signal, the myState variable
> automatically gets updated without the need of going through a routine.
> This could work similar with other objects. This also works better with
> refactoring than the string method approach. The objects beeing
> initialized through this way would need to have a constructor that is
> free of arguments of course, and one could even then do the coding in
> the constructor that is handeled in the method passed as string in the
> current approach.

-- 
 [ signature omitted ] 

Attachment: pgpSsenwNOTQ0.pgp
Description: PGP signature


Message 3 in thread

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hmm, <br>
<br>
I'm not quite sure I understand what you are trying to say.<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Boolean a = false;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Boolean b = true;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a = b;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; System.out.println(a);<br>
<br>
This test prints true, so refreshing a with a new object shouldn't be a
problem...<br>
<br>
PS: In my suggestion, I'm not just referring to Booleans, but to any
object with zero length constructors.<br>
These constructors might be triggered using java reflection.<br>
<br>
Helge<br>
<br>
Thomas Zander wrote:
<blockquote cite="mid200610171148.42091.zander@xxxxxxx" type="cite">
  <pre wrap="">I think you made a thinko, a Boolean is immutable so referencing the object 
will not help since it would never change.

On Tuesday 17 October 2006 10:47, Helge Fredriksen wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">One thing I see that would be really neat is direct initialization of
objects when signals are emitted. That is, the possibility to put
an Object of same type that is emitted in the connect statement.

Like this

protected Boolean myState;

mySignalSender.stateEmitter.connect(this, myState);

When the mySignalSender instance sends a signal, the myState variable
automatically gets updated without the need of going through a routine.
This could work similar with other objects. This also works better with
refactoring than the string method approach. The objects beeing
initialized through this way would need to have a constructor that is
free of arguments of course, and one could even then do the coding in
the constructor that is handeled in the method passed as string in the
current approach.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
  </pre>
</blockquote>
<br>
</body>
</html>


Message 4 in thread

Helge Fredriksen wrote:
> Hmm,
> 
> I'm not quite sure I understand what you are trying to say.
> 
>         Boolean a = false;
>         Boolean b = true;
>         a = b;
>         System.out.println(a);
> 
> This test prints true, so refreshing a with a new object shouldn't be a problem...
> 
> PS: In my suggestion, I'm not just referring to Booleans, but to any object with 
> zero length constructors.
> These constructors might be triggered using java reflection.
> 
> Helge

Hi Helge,

The point would be:

void change(Boolean x) {
   x = true;
}

void tryit() {
   Boolean value = false;
   change(value);
   System.out.println(value); // will print false
}

---

Because your only changing the local copy of x in the function change(). 
For this to work one has to have set'er functions like setBoolean() for 
the Boolean type, but the boolean type and all the other primitives are 
immutable.

---

best regards,
Gunnar