Digital Mars - D - signals and slots

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

↑ ↓ ← → 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

↑ ↓ ← → 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

↑ ↓ ← → "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




 to build whatever notification service she would desire.
 It could be something simple as a new member function similar to




 except that the purpose of its existens would be to contain the




 notification sceme.
 Such a function (lets call it notifyChange() for the purpose of




 implicitly be called whenever a memer function has been called. The




 would be responsible of implementing the body of notifyChange() so that




 check for any changes in the objects state and send notifications




 Kind regards,
 Erik

 In article <bivq6h$1sis$1 digitaldaemon.com>, Achilleas Margaritis




I think a nice addition to the language would be a native signal and






mechanism. Since D's success would depend a lot on the available GUI






(that's my opinion, I don't want to start a flamewar), and the signals






slots is a natural way for objects to communicate (especially GUI






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






delegates. But the same could be said about maps (assosiative arrays in






terminology) and other functionality.

Personally, I use signals and slots heavily, even in console apps,






it helps in the design a lot. Since C++ does not provide a standard






and slots mechanism, I either have to program my own, use some third






lib or use Qt (which my company have bought for the projects of my
department). I think D should incorporate the signals and slots






the language, in order to avoid the problem of which library to use, and






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






a need to have different signal and slot classes for each given number






arguments (that's why C++ libraries provide classes like signal0,






signal2, slot0, slot1, slot2, etc), whereas in the native solution all






are avoided.

Sep 02 2003

↑ ↓ ← → "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

↑ ↓ ← → "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


 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



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,


 get a library with a String class that has a buggy or slow implementation


 '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

↑ ↓ ← → "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




 instances that could be created from a class. In case of a single


 any successive 'new' would return a pointer to the original instance;




 the first 'new' would actually create the object.


 I find the "number of instances" concept interesting: it not only allows


 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


 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


 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




 every possible call, a message could be passed to a derived class




 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




 the vtable which does a 'switch' on the enumeration, calling the method




 it exists, otherwise delegating the message to the method of the



 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


 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




 I
 get a library with a String class that has a buggy or slow




 of
 'find(String)'. I could provide my own implementation of the function




 is safe.


 :) This might be done in C++ with function-level linking...

 Instead of the "class String: public String" from, I propose this one,


 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


 even add methods to the class, which is neither possible nor desirable


 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

↑ ↓ ← → "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


 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

↑ ↓ ← → "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


 to build whatever notification service she would desire.
 It could be something simple as a new member function similar to


 except that the purpose of its existens would be to contain the programmer


 notification sceme.
 Such a function (lets call it notifyChange() for the purpose of argument)


 implicitly be called whenever a memer function has been called. The


 would be responsible of implementing the body of notifyChange() so that it


 check for any changes in the objects state and send notifications


 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




(that's my opinion, I don't want to start a flamewar), and the signals




slots is a natural way for objects to communicate (especially GUI




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




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,




it helps in the design a lot. Since C++ does not provide a standard




and slots mechanism, I either have to program my own, use some third




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




the language, in order to avoid the problem of which library to use, and




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




a need to have different signal and slot classes for each given number of
arguments (that's why C++ libraries provide classes like signal0,




signal2, slot0, slot1, slot2, etc), whereas in the native solution all




are avoided.

Sep 04 2003

↑ ↓ ← → 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

↑ ↓ ← → "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
specification. Just like C# has the 'event' attribute.

"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




 mechanism. Since D's success would depend a lot on the available GUI




 (that's my opinion, I don't want to start a flamewar), and the signals




 slots is a natural way for objects to communicate (especially GUI




 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




 delegates. But the same could be said about maps (assosiative arrays in




 terminology) and other functionality.

 Personally, I use signals and slots heavily, even in console apps,




 it helps in the design a lot. Since C++ does not provide a standard




 and slots mechanism, I either have to program my own, use some third




 lib or use Qt (which my company have bought for the projects of my
 department). I think D should incorporate the signals and slots




 the language, in order to avoid the problem of which library to use, and




 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

Sep 02 2003

↑ ↓ ← → 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
 specification. Just like C# has the 'event' attribute.


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 
fact, it's almost exactly the same as C#.

D:
    instance TListener(MouseEvent) MouseListener;
    MouseListener.Listener onMouseMove;
    onMouseMove += &this.handleMouseMovement;

C#:
    delegate void MouseEventHandler(MouseEvent);
    event MouseEventHandler onMouseMove;
    onMouseMove += new MouseEventHandler(this.handleMouseMovement)

  -- andy

Sep 03 2003

↑ ↓ ← → "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,




 use and less confusion it would be nice to be in the programming




 specification. Just like C# has the 'event' attribute.


 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
 fact, it's almost exactly the same as C#.

 D:
     instance TListener(MouseEvent) MouseListener;
     MouseListener.Listener onMouseMove;
     onMouseMove += &this.handleMouseMovement;

 C#:
     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

↑ ↓ ← → 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