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

"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
> > 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.

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.
>
>

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.
> >
> >
> >
>
>