www.digitalmars.com         C & C++   DMDScript  

D - signals and slots

reply "Achilleas Margaritis" <axilmar in.gr> writes:
I think a nice addition to the language would be a native signal and slot
mechanism. Since D's success would depend a lot on the available GUI library
(that's my opinion, I don't want to start a flamewar), and the signals and
slots is a natural way for objects to communicate (especially GUI objects),
I think the language would benefit from such a mechanism.

It has been said that it's easy to wrap a signals and slots mechanism around
delegates. But the same could be said about maps (assosiative arrays in D
terminology) and other functionality.

Personally, I use signals and slots heavily, even in console apps, because
it helps in the design a lot. Since C++ does not provide a standard signals
and slots mechanism, I either have to program my own, use some third party
lib or use Qt (which my company have bought for the projects of my
department). I think D should incorporate the signals and slots mechanism in
the language, in order to avoid the problem of which library to use, and to
lend itself to more elegant code.

A 'signal' and 'slot' keyword should be added. For example:

class PacketReceiver {
    public signal packetReceived(Packet);
}

class PacketProcessor {
    public slot packetReceived(Packet) {
    }
}

PacketReceiver receiver;
PacketProcessor processor;

receiver.packetReceived += processor.packetReceived;

I find the above syntax very clean and elegant, and much better when
compared to a template solution. Not only that, but with templates there is
a need to have different signal and slot classes for each given number of
arguments (that's why C++ libraries provide classes like signal0, signal1,
signal2, slot0, slot1, slot2, etc), whereas in the native solution all these
are avoided.
Sep 01 2003
next sibling parent reply ebaklund hotmail.com writes:
I second that suggestion.
Either that or some lightweigth aspect support that would allow the programmer
to build whatever notification service she would desire.
It could be something simple as a new member function similar to invariant(),
except that the purpose of its existens would be to contain the programmer coded
notification sceme.
Such a function (lets call it notifyChange() for the purpose of argument) would
implicitly be called whenever a memer function has been called. The programmer
would be responsible of implementing the body of notifyChange() so that it would
check for any changes in the objects state and send notifications accordingly.

Kind regards,
Erik

In article <bivq6h$1sis$1 digitaldaemon.com>, Achilleas Margaritis says...
I think a nice addition to the language would be a native signal and slot
mechanism. Since D's success would depend a lot on the available GUI library
(that's my opinion, I don't want to start a flamewar), and the signals and
slots is a natural way for objects to communicate (especially GUI objects),
I think the language would benefit from such a mechanism.

It has been said that it's easy to wrap a signals and slots mechanism around
delegates. But the same could be said about maps (assosiative arrays in D
terminology) and other functionality.

Personally, I use signals and slots heavily, even in console apps, because
it helps in the design a lot. Since C++ does not provide a standard signals
and slots mechanism, I either have to program my own, use some third party
lib or use Qt (which my company have bought for the projects of my
department). I think D should incorporate the signals and slots mechanism in
the language, in order to avoid the problem of which library to use, and to
lend itself to more elegant code.

A 'signal' and 'slot' keyword should be added. For example:

class PacketReceiver {
    public signal packetReceived(Packet);
}

class PacketProcessor {
    public slot packetReceived(Packet) {
    }
}

PacketReceiver receiver;
PacketProcessor processor;

receiver.packetReceived += processor.packetReceived;

I find the above syntax very clean and elegant, and much better when
compared to a template solution. Not only that, but with templates there is
a need to have different signal and slot classes for each given number of
arguments (that's why C++ libraries provide classes like signal0, signal1,
signal2, slot0, slot1, slot2, etc), whereas in the native solution all these
are avoided.
Sep 01 2003
next sibling parent reply Jotham <jotham ourbrisbane.com> writes:
An interesting exercise would be to go through the various proven design 
patterns (ie. http://home.earthlink.net/~huston2/dp/patterns.html) and 
see how easy/lightweight they are to implement in D.  A bit above my 
ability at the moment as I'm just starting to learn them more formally 
now but I keep finding that most of the advanced/convulted features in 
C++ are just there so a programmer can push,prod and cajoule the 
language into acting in these ways which were not envisioned by its 
original creators.

I'm a fan of the Observer pattern too (events and 
eventListeners/notifiers) and would definately like to see this 
supported simply in D.

ebaklund hotmail.com wrote:
 I second that suggestion.
 Either that or some lightweigth aspect support that would allow the programmer
 to build whatever notification service she would desire.
 It could be something simple as a new member function similar to invariant(),
 except that the purpose of its existens would be to contain the programmer
coded
 notification sceme.
 Such a function (lets call it notifyChange() for the purpose of argument) would
 implicitly be called whenever a memer function has been called. The programmer
 would be responsible of implementing the body of notifyChange() so that it
would
 check for any changes in the objects state and send notifications accordingly.
 
 Kind regards,
 Erik
 
 In article <bivq6h$1sis$1 digitaldaemon.com>, Achilleas Margaritis says...
 
I think a nice addition to the language would be a native signal and slot
mechanism. Since D's success would depend a lot on the available GUI library
(that's my opinion, I don't want to start a flamewar), and the signals and
slots is a natural way for objects to communicate (especially GUI objects),
I think the language would benefit from such a mechanism.

It has been said that it's easy to wrap a signals and slots mechanism around
delegates. But the same could be said about maps (assosiative arrays in D
terminology) and other functionality.

Personally, I use signals and slots heavily, even in console apps, because
it helps in the design a lot. Since C++ does not provide a standard signals
and slots mechanism, I either have to program my own, use some third party
lib or use Qt (which my company have bought for the projects of my
department). I think D should incorporate the signals and slots mechanism in
the language, in order to avoid the problem of which library to use, and to
lend itself to more elegant code.

A 'signal' and 'slot' keyword should be added. For example:

class PacketReceiver {
   public signal packetReceived(Packet);
}

class PacketProcessor {
   public slot packetReceived(Packet) {
   }
}

PacketReceiver receiver;
PacketProcessor processor;

receiver.packetReceived += processor.packetReceived;

I find the above syntax very clean and elegant, and much better when
compared to a template solution. Not only that, but with templates there is
a need to have different signal and slot classes for each given number of
arguments (that's why C++ libraries provide classes like signal0, signal1,
signal2, slot0, slot1, slot2, etc), whereas in the native solution all these
are avoided.
Sep 02 2003
parent reply "Achilleas Margaritis" <axilmar in.gr> writes:
After reading the material at the given link (about design patterns), here
are my ideas:

1) signals and slots are definitely needed in D. Software componentization
is one of the basic, if not the basic, software engineering technique.

2) singletons are quite nice; D could impose restrictions on the number of
instances that could be created from a class. In case of a single instance,
any successive 'new' would return a pointer to the original instance; only
the first 'new' would actually create the object.

3) cloning is good; it allows for duplicating objects without knowing their
type; this can be an operator ('clone' for example, and used just like
'new').

4) factory is good; it allows to create classes without actually knowing the
class type. It would also be a lot cooler if an instance could be also be
created from a class name (string). It would allow for more dynamic
applications, and would make GUI IDE writing easier.

Some other ideas:

1) message passing. Instead of a base class having myriads of methods for
every possible call, a message could be passed to a derived class without
the base class declaring it. The logic behind this is that 'not everyone
processes a message'.

It could be implemented by having a special keyword 'message' that
accompanies each method. Then, at compile time, the compiler creates an
implicit enumeration with all the possible messages, and adds a method at
the vtable which does a 'switch' on the enumeration, calling the method if
it exists, otherwise delegating the message to the method of the superclass.

Example:

class Base {
}

class Derived1 : public Base {
    public message void actionA(string name) {
    }
}

class Derived2 : public Base {
    public message void ActionB(int number) {
    }
}

Base *b1 = new Derived1();
Base *b2 = new Derived2();

//calling 'actionA' as a message
b1.actionA("name");

//calling 'actionB' as a message
b2.actionB(10);

The C++ equivalent would be:

enum MESSAGE {
    ACTIONA,
    ACTIONB
}

class Base {
public:
    virtual void messageProc(MESSAGE msg, ...);
};

class Derived1 : public Base {
public:
    virtual void messageProc(MESSAGE msg, ...) {
        switch (msg) {
            case ACTIONA:
                  actionA(va_arg(const char *));
                break;
        }
    }

    void actionA(const char *str) {
    }
};

class Derived2 : public Base {
public:
    virtual void messageProc(MESSAGE msg, ...) {
        switch (msg) {
            case ACTIONB:
                  actionB(va_arg(int));
                break;
        }
    }

    void actionB(int i) {
    }
};

This would allow to pass messages to objects without the objects needing to
have the interface. In other words, it would be like automating message
handlers based on message ids.

2) the ability to define a class after it has been compiled. For example, I
get a library with a String class that has a buggy or slow implementation of
'find(String)'. I could provide my own implementation of the function that
is safe. For example:

import String;

class String : public String {
public:
    //safe 'find'
    index find(String s) {
        if (s == null) ...
    }
}

This 'new' definition of the String class could be used in place of the old
definition, solving elegantly some problems.

"Jotham" <jotham ourbrisbane.com> wrote in message
news:bj28hh$29pc$1 digitaldaemon.com...
 An interesting exercise would be to go through the various proven design
 patterns (ie. http://home.earthlink.net/~huston2/dp/patterns.html) and
 see how easy/lightweight they are to implement in D.  A bit above my
 ability at the moment as I'm just starting to learn them more formally
 now but I keep finding that most of the advanced/convulted features in
 C++ are just there so a programmer can push,prod and cajoule the
 language into acting in these ways which were not envisioned by its
 original creators.

 I'm a fan of the Observer pattern too (events and
 eventListeners/notifiers) and would definately like to see this
 supported simply in D.

 ebaklund hotmail.com wrote:
 I second that suggestion.
 Either that or some lightweigth aspect support that would allow the
programmer
 to build whatever notification service she would desire.
 It could be something simple as a new member function similar to
invariant(),
 except that the purpose of its existens would be to contain the
programmer coded
 notification sceme.
 Such a function (lets call it notifyChange() for the purpose of
argument) would
 implicitly be called whenever a memer function has been called. The
programmer
 would be responsible of implementing the body of notifyChange() so that
it would
 check for any changes in the objects state and send notifications
accordingly.
 Kind regards,
 Erik

 In article <bivq6h$1sis$1 digitaldaemon.com>, Achilleas Margaritis
says...
I think a nice addition to the language would be a native signal and
slot
mechanism. Since D's success would depend a lot on the available GUI
library
(that's my opinion, I don't want to start a flamewar), and the signals
and
slots is a natural way for objects to communicate (especially GUI
objects),
I think the language would benefit from such a mechanism.

It has been said that it's easy to wrap a signals and slots mechanism
around
delegates. But the same could be said about maps (assosiative arrays in
D
terminology) and other functionality.

Personally, I use signals and slots heavily, even in console apps,
because
it helps in the design a lot. Since C++ does not provide a standard
signals
and slots mechanism, I either have to program my own, use some third
party
lib or use Qt (which my company have bought for the projects of my
department). I think D should incorporate the signals and slots
mechanism in
the language, in order to avoid the problem of which library to use, and
to
lend itself to more elegant code.

A 'signal' and 'slot' keyword should be added. For example:

class PacketReceiver {
   public signal packetReceived(Packet);
}

class PacketProcessor {
   public slot packetReceived(Packet) {
   }
}

PacketReceiver receiver;
PacketProcessor processor;

receiver.packetReceived += processor.packetReceived;

I find the above syntax very clean and elegant, and much better when
compared to a template solution. Not only that, but with templates there
is
a need to have different signal and slot classes for each given number
of
arguments (that's why C++ libraries provide classes like signal0,
signal1,
signal2, slot0, slot1, slot2, etc), whereas in the native solution all
these
are avoided.
Sep 02 2003
next sibling parent "Carlos Santander B." <carlos8294 msn.com> writes:
"Achilleas Margaritis" <axilmar in.gr> wrote in message
news:bj2gkr$2l4a$1 digitaldaemon.com...
| ...
| 2) singletons are quite nice; D could impose restrictions on the number of
| instances that could be created from a class. In case of a single
instance,
| any successive 'new' would return a pointer to the original instance; only
| the first 'new' would actually create the object.
|

Someone (Daniel, IIRC) already posted once how to implement a singleton in
D.

| 3) cloning is good; it allows for duplicating objects without knowing
their
| type; this can be an operator ('clone' for example, and used just like
| 'new').
|
| 4) factory is good; it allows to create classes without actually knowing
the
| class type. It would also be a lot cooler if an instance could be also be
| created from a class name (string). It would allow for more dynamic
| applications, and would make GUI IDE writing easier.
|

These two I definitively would like to see implemented.

—————————————————————————
Carlos Santander


---

Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.515 / Virus Database: 313 - Release Date: 2003-09-01
Sep 02 2003
prev sibling parent reply "Riccardo De Agostini" <riccardo.de.agostini email.it> writes:
"Achilleas Margaritis" <axilmar in.gr> ha scritto nel messaggio
news:bj2gkr$2l4a$1 digitaldaemon.com...

 2) singletons are quite nice; D could impose restrictions on the number of
 instances that could be created from a class. In case of a single
instance,
 any successive 'new' would return a pointer to the original instance; only
 the first 'new' would actually create the object.
I find the "number of instances" concept interesting: it not only allows for singletons, but for object polls too, server sockets and worker threads being the first two applications that come to my mind. There should be a class function (oops... speaking Delphi! I mean a static function) which chooses the object that new is to return. But overloading the new operator does the same thing, as long as it can be done in D, which I don't remember at the moment. Furthermore, I don't think there's any need to use the new operator for singletons. Since a singleton is no more that a class whose members are all static, using the class name directly instead of an object reference seems to make more sense. BTW, static virtual methods would be nice indeed. Delphi (again!) has them and I've found them quite useful.
 1) message passing. Instead of a base class having myriads of methods for
 every possible call, a message could be passed to a derived class without
 the base class declaring it. The logic behind this is that 'not everyone
 processes a message'.

 It could be implemented by having a special keyword 'message' that
 accompanies each method. Then, at compile time, the compiler creates an
 implicit enumeration with all the possible messages, and adds a method at
 the vtable which does a 'switch' on the enumeration, calling the method if
 it exists, otherwise delegating the message to the method of the
superclass. Better yet, if the enumeration could be built from explicitly specified values, this could be great for Windows "message crunching". Now, I don't want to be boring, but Delphi has it... (Don't misunderstand me; I'm *not* saying that Delphi is any better than D. By coincidence, though, several of D's enhancements over C++ resemble Delphi, so comparisons come to mind quite naturally).
 2) the ability to define a class after it has been compiled. For example,
I
 get a library with a String class that has a buggy or slow implementation
of
 'find(String)'. I could provide my own implementation of the function that
 is safe.
:) This might be done in C++ with function-level linking... Instead of the "class String: public String" from, I propose this one, which does not require to be surrounded by a class pseudo-declaration: substitute index String.find(String s) { ... } The advantage is that it makes clearer that the method must be already defined in the class, while the pseudo-declaration form _looks_ like you can even add methods to the class, which is neither possible nor desirable IMO. A question: what if you substitute the same method more than once? Ric
Sep 03 2003
parent reply "Achilleas Margaritis" <axilmar in.gr> writes:
"Riccardo De Agostini" <riccardo.de.agostini email.it> wrote in message
news:bj4blj$286l$1 digitaldaemon.com...
 "Achilleas Margaritis" <axilmar in.gr> ha scritto nel messaggio
 news:bj2gkr$2l4a$1 digitaldaemon.com...

 2) singletons are quite nice; D could impose restrictions on the number
of
 instances that could be created from a class. In case of a single
instance,
 any successive 'new' would return a pointer to the original instance;
only
 the first 'new' would actually create the object.
I find the "number of instances" concept interesting: it not only allows
for
 singletons, but for object polls too, server sockets and worker threads
 being the first two applications that come to my mind. There should be a
 class function (oops... speaking Delphi! I mean a static function) which
 chooses the object that new is to return. But overloading the new operator
 does the same thing, as long as it can be done in D, which I don't
remember
 at the moment.

 Furthermore, I don't think there's any need to use the new operator for
 singletons. Since a singleton is no more that a class whose members are
all
 static, using the class name directly instead of an object reference seems
 to make more sense.

 BTW, static virtual methods would be nice indeed. Delphi (again!) has them
 and I've found them quite useful.

 1) message passing. Instead of a base class having myriads of methods
for
 every possible call, a message could be passed to a derived class
without
 the base class declaring it. The logic behind this is that 'not everyone
 processes a message'.

 It could be implemented by having a special keyword 'message' that
 accompanies each method. Then, at compile time, the compiler creates an
 implicit enumeration with all the possible messages, and adds a method
at
 the vtable which does a 'switch' on the enumeration, calling the method
if
 it exists, otherwise delegating the message to the method of the
superclass. Better yet, if the enumeration could be built from explicitly specified values, this could be great for Windows "message crunching". Now, I don't want to be boring, but Delphi has it... (Don't misunderstand me; I'm *not* saying that Delphi is any better than
D.
 By coincidence, though, several of D's enhancements over C++ resemble
 Delphi, so comparisons come to mind quite naturally).

 2) the ability to define a class after it has been compiled. For
example,
 I
 get a library with a String class that has a buggy or slow
implementation
 of
 'find(String)'. I could provide my own implementation of the function
that
 is safe.
:) This might be done in C++ with function-level linking... Instead of the "class String: public String" from, I propose this one,
which
 does not require to be surrounded by a class pseudo-declaration:

 substitute index String.find(String s) { ... }

 The advantage is that it makes clearer that the method must be already
 defined in the class, while the pseudo-declaration form _looks_ like you
can
 even add methods to the class, which is neither possible nor desirable
IMO.
 A question: what if you substitute the same method more than once?

 Ric
The last met substitution shall be effective. If there are two substitutions in the same context, the compiler would declare an error.
Sep 03 2003
parent "Riccardo De Agostini" <riccardo.de.agostini email.it> writes:
"Achilleas Margaritis" <axilmar in.gr> ha scritto nel messaggio
news:bj4cg9$297g$1 digitaldaemon.com...
 The last met substitution shall be effective. If there are two
substitutions
 in the same context, the compiler would declare an error.
Now that I think about it... how can there be more than one method of the same class with the same signature? Shouldn't the linker leave out all such methods but one (probably the first one it encounters)? It's the same as if, in C, you replace a library function with your own: the library implementation doesn't get linked in the executable. This, of course, only works with libraries; if the same global symbol is defined in two or more non-library modules, a linker error (or sometimes just a warning?) occurs. So, to make substitutions work, a linker should be D-aware, in the sense that it should deal with duplicate method symbols differently, i.e. not give any warning on duplicate methods but retain the substitute and discard the "original"; this could imply a change in the object file format, too. Though _more than one_ substitutes of the same method should cause at least a warning, IMO. Ric
Sep 03 2003
prev sibling parent "Achilleas Margaritis" <axilmar in.gr> writes:
Walter has not shared his opinion on signals and slots yet. Hey Walter, what
do you think ?

<ebaklund hotmail.com> wrote in message
news:bj0fqs$2pt4$1 digitaldaemon.com...
 I second that suggestion.
 Either that or some lightweigth aspect support that would allow the
programmer
 to build whatever notification service she would desire.
 It could be something simple as a new member function similar to
invariant(),
 except that the purpose of its existens would be to contain the programmer
coded
 notification sceme.
 Such a function (lets call it notifyChange() for the purpose of argument)
would
 implicitly be called whenever a memer function has been called. The
programmer
 would be responsible of implementing the body of notifyChange() so that it
would
 check for any changes in the objects state and send notifications
accordingly.
 Kind regards,
 Erik

 In article <bivq6h$1sis$1 digitaldaemon.com>, Achilleas Margaritis says...
I think a nice addition to the language would be a native signal and slot
mechanism. Since D's success would depend a lot on the available GUI
library
(that's my opinion, I don't want to start a flamewar), and the signals
and
slots is a natural way for objects to communicate (especially GUI
objects),
I think the language would benefit from such a mechanism.

It has been said that it's easy to wrap a signals and slots mechanism
around
delegates. But the same could be said about maps (assosiative arrays in D
terminology) and other functionality.

Personally, I use signals and slots heavily, even in console apps,
because
it helps in the design a lot. Since C++ does not provide a standard
signals
and slots mechanism, I either have to program my own, use some third
party
lib or use Qt (which my company have bought for the projects of my
department). I think D should incorporate the signals and slots mechanism
in
the language, in order to avoid the problem of which library to use, and
to
lend itself to more elegant code.

A 'signal' and 'slot' keyword should be added. For example:

class PacketReceiver {
    public signal packetReceived(Packet);
}

class PacketProcessor {
    public slot packetReceived(Packet) {
    }
}

PacketReceiver receiver;
PacketProcessor processor;

receiver.packetReceived += processor.packetReceived;

I find the above syntax very clean and elegant, and much better when
compared to a template solution. Not only that, but with templates there
is
a need to have different signal and slot classes for each given number of
arguments (that's why C++ libraries provide classes like signal0,
signal1,
signal2, slot0, slot1, slot2, etc), whereas in the native solution all
these
are avoided.
Sep 04 2003
prev sibling parent reply Andy Friesen <andy ikagames.com> writes:
Achilleas Margaritis wrote:
 I think a nice addition to the language would be a native signal and slot
 mechanism. Since D's success would depend a lot on the available GUI library
 (that's my opinion, I don't want to start a flamewar), and the signals and
 slots is a natural way for objects to communicate (especially GUI objects),
 I think the language would benefit from such a mechanism.
 
 It has been said that it's easy to wrap a signals and slots mechanism around
 delegates. But the same could be said about maps (assosiative arrays in D
 terminology) and other functionality.
 
 Personally, I use signals and slots heavily, even in console apps, because
 it helps in the design a lot. Since C++ does not provide a standard signals
 and slots mechanism, I either have to program my own, use some third party
 lib or use Qt (which my company have bought for the projects of my
 department). I think D should incorporate the signals and slots mechanism in
 the language, in order to avoid the problem of which library to use, and to
 lend itself to more elegant code.
Maybe I'm missing something, but signals and slots are extremely easy to implement with templates. (maybe adding them to Phobos would be worthwhile)
Sep 02 2003
parent reply "Achilleas Margaritis" <axilmar b-online.gr> writes:
Sure, it's trivial to implement with templates. But for readability, ease of
use and less confusion it would be nice to be in the programming language


"Andy Friesen" <andy ikagames.com> wrote in message
news:bj2rd0$338$1 digitaldaemon.com...
 Achilleas Margaritis wrote:
 I think a nice addition to the language would be a native signal and
slot
 mechanism. Since D's success would depend a lot on the available GUI
library
 (that's my opinion, I don't want to start a flamewar), and the signals
and
 slots is a natural way for objects to communicate (especially GUI
objects),
 I think the language would benefit from such a mechanism.

 It has been said that it's easy to wrap a signals and slots mechanism
around
 delegates. But the same could be said about maps (assosiative arrays in
D
 terminology) and other functionality.

 Personally, I use signals and slots heavily, even in console apps,
because
 it helps in the design a lot. Since C++ does not provide a standard
signals
 and slots mechanism, I either have to program my own, use some third
party
 lib or use Qt (which my company have bought for the projects of my
 department). I think D should incorporate the signals and slots
mechanism in
 the language, in order to avoid the problem of which library to use, and
to
 lend itself to more elegant code.
Maybe I'm missing something, but signals and slots are extremely easy to implement with templates. (maybe adding them to Phobos would be
worthwhile)

Sep 02 2003
parent reply Andy Friesen <andy ikagames.com> writes:
Achilleas Margaritis wrote:

 Sure, it's trivial to implement with templates. But for readability, ease of
 use and less confusion it would be nice to be in the programming language

I've already implemented this sort of thing in D before. It's not hard to do, and the resulting template is extremely easy to use and read. In D: instance TListener(MouseEvent) MouseListener; MouseListener.Listener onMouseMove; onMouseMove += &this.handleMouseMovement; delegate void MouseEventHandler(MouseEvent); event MouseEventHandler onMouseMove; onMouseMove += new MouseEventHandler(this.handleMouseMovement) -- andy
Sep 03 2003
parent reply "Achilleas Margaritis" <axilmar in.gr> writes:
"Andy Friesen" <andy ikagames.com> wrote in message
news:bj6bbo$1thg$1 digitaldaemon.com...
 Achilleas Margaritis wrote:

 Sure, it's trivial to implement with templates. But for readability,
ease of
 use and less confusion it would be nice to be in the programming
language

I've already implemented this sort of thing in D before. It's not hard to do, and the resulting template is extremely easy to use and read. In D: instance TListener(MouseEvent) MouseListener; MouseListener.Listener onMouseMove; onMouseMove += &this.handleMouseMovement; delegate void MouseEventHandler(MouseEvent); event MouseEventHandler onMouseMove; onMouseMove += new MouseEventHandler(this.handleMouseMovement) -- andy
I like it better like this: class Window { public signal onMouseMove(Event &event); } class Button { public slot mouseMoved(Event &event); } Button btn; btn.onMouseMove += mouseMoved; The advantages are: 1) you don't need the 'instance' keyword. 2) signals and slots can have any number of parameters; there is no need for separate classes for different numbers of parameters. 3) signals and slots will be reflected, i.e. be available in the run-time information of a class, making it easier for IDEs. 4) there is no need for external libraries. Since 99% of software carries some sort of callback mechanism, why should it be in a library ? and it avoids library confusion, incompatibilities, etc.
Sep 04 2003
parent Felix <Felix_member pathlink.com> writes:
I think is perfect the way you say it. I simply love the stile.
One more thing, I hate the __ and _ before and in the keywords... (but I  am not
fanatic). Not for this problem, but I wonder why they are in the language.

Felix



In article <bj6u8n$2pgv$1 digitaldaemon.com>, Achilleas Margaritis says...
class Window {
    public signal onMouseMove(Event &event);
}

class Button {
    public slot mouseMoved(Event &event);
}

Button btn;
btn.onMouseMove += mouseMoved;

The advantages are:

1) you don't need the 'instance' keyword.
2) signals and slots can have any number of parameters; there is no need for
separate classes for different numbers of parameters.
3) signals and slots will be reflected, i.e. be available in the run-time
information of a class, making it easier for IDEs.
4) there is no need for external libraries. Since 99% of software carries
some sort of callback mechanism, why should it be in a library ? and it
avoids library confusion, incompatibilities, etc.
Sep 04 2003