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.

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

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

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

"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

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)

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

"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

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

"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