"Chris Sauls" <ibisbasenji@gmail.com> wrote in message news:cv1ask$26ed$1@digitaldaemon.com...
> You don't need multiple templates... you need templates that take a delegate type as their parameter.  Aka:
>
> #
> #  class Event(alias DgType) {
> #    this(doublt t, DgType dg, char[] str);
> #  }
> #
>
> Then you would just call for template instances for your signatures. Some examples:
>
> #
> #  // using the template with a two-param delegate
> #  alias Event!(void delegate(int,int)) Event_ii;
> #  Event_ii iievent = new Event_ii(dg);
> #
> #  // using the template with a one-param delegate
> #  alias Event!(void delegate(char[])) Event_s;
> #  Event_s event = new Event_s(dg);
> #
>
> -- Chris S
>

The above implementation is not adequate.  Again, the event needs to contain the delegate PLUS any associated parameters, not just the delegate itself.

-Craig

Are you serious!?  D currently supports this syntax?
Where in the specs is the documentation for this?

-Craig

"Craig Black" wrote:

[...]
> D currently supports this syntax?
[...]

No. I said "want" and "would". But to me this seems very natural. A while ago I talked of computing on signatures but didn't made it into the specs. Instead signatures are now messed up with C++-like optional parameters. This may hinder the introduction of the proposed example syntax and the completion of your task in total.

-manfred

"Craig Black" <cblack@ara.com> wrote:

> Are you serious!?
[...]

Thinking this over:

<example>
class Event{
  this( double time,
        delegate dg1, signature s1;
        delegate dg2, signature s2){
    dg( s);
  }
}
// ...
Event e= new Event( 1.0,
                    &myFunc1, ( actualParm1_1, ..., actualParm1_n),
                    &myFunc2, ( actualParm2_1, ..., actualParm2_m)
                    );
</example>

I noticed, that the function the compiler uses to do its work should be made available to the user through the module std.compiler.

This given the example could be rewritten:

<example>
private import std.compiler;
class Event{
  this( double time,
        delegate dg1, signature s1,
        delegate dg2, signature s2){
    static assert(
      std.compiler.isSignatureMatch(
          std.compiler.theSignature( dg1),
          s1
      )
    );
    dg1( s1);

  }
}
// ...
Event e= new Event( 1.0,
                    &myFunc1, ( actualParm1_1, ..., actualParm1_n),
                    &myFunc2, ( actualParm2_1, ..., actualParm2_m)
                    );
</example>

Note that restricting the usage of allSignature function/delegate constnats and signature constants to the formal parameters of functions/delegates, static asserts and functions from std.compiler does not compromise the type safety of the language.

-manfred

Just a random thought from a guy who just got home from work and probably doesn't have enough brain cells active at the moment... :)

Would it be possible to put something together using an array of TypeInfo's?

-- Chris S

Manfred Nowak wrote:
> "Craig Black" wrote:
> 
> [...]
> 
>>D currently supports this syntax?
> 
> [...]
> 
> No. I said "want" and "would". But to me this seems very natural. A while ago I talked of computing on signatures but didn't made it into the specs. Instead signatures are now messed up with C++-like optional parameters. This may hinder the introduction of the proposed example syntax and the completion of your task in total.
> 
> -manfred

Rather than adding new syntax to allow for an Event class to be defined, why not have event as a native type in the D language, just like function and delegate?  This I think would be simpler.  I can't think of any other usage of the signature syntax that you propose than for events.  Can you?

-Craig

"Craig Black" <cblack@ara.com> wrote:

[...]
> why not have event as a native type in the D language,
[...]

You are right, that setting up events as a new basic type for D would render syntactic changes useless. But to set up a new basic type for every unfulfilled problem that might arise would poison the set of basic types with another instance.

To avoid this poisoning at least one of the following statements
must hold:
1. it is proven that the problem can not be decomposed into smaller
subproblems
2. the problem can be decomposed into smaller subproblems but it is
proven that none of the solutions to the smaller subproblems is of
any benefit for any problem other than the originating one.

It is not a prove of no benefit to be unable to think of any problem in which a partial solution have any benefit. And you may admit, that although I am able to establish an example that shows that the solution of a decomposition _can_ be used, I would not be able to convince _everyone_ of the benefits of this usage. This might be due to the fact that the decomposition lays the roots of a whole new programming paradigma.

And as you may admit further: introducing a new basic type for a language _is_ more or less undistinguishable from the introduction of a whole new pogramming paradigma.

-manfred

> You are right, that setting up events as a new basic type for D would render syntactic changes useless. But to set up a new basic type for every unfulfilled problem that might arise would poison the set of basic types with another instance.

Events are a generic language feature.  They are commonly used for numerous purposes, notably for GUI programming.  I do not think that adding an event primitive to D would at all poison the syntax.  Rather, it would add richness and elegance.

-Craig

Craig Black wrote:
>>You are right, that setting up events as a new basic type for D
>>would render syntactic changes useless. But to set up a new basic
>>type for every unfulfilled problem that might arise would poison
>>the set of basic types with another instance.
> 
> 
> Events are a generic language feature.  They are commonly used for numerous purposes, notably for GUI programming.  I do not think that adding an event primitive to D would at all poison the syntax.  Rather, it would add richness and elegance.

Considering the plethora of GUI toolkits and frameworks, is it possible
that the concept of Events is confined and stable enough to actually
be covered with a single type in D?

I'm not against the idea, it's just that so far I have a hard time
imagining that we can get by with just one type.

"Craig Black" <cblack@ara.com> wrote:

[...]
> Events are a generic language feature.

You want them to become so.

> They are commonly used for numerous purposes, notably for GUI programming.

And which language designer already followed your proposal? And if he did not follow what was wrong with his arguments for not following?

> I do not think that adding an event primitive to D would at all poison the syntax.  Rather, it would add richness and elegance.

How do you measure richness or elegance against poisoning of the set of basic types? And would you admit that every other proposal with an outcome in this area that at least equals the measure your proposal reach must be also incorporated into the language D? Can it be, that the most rich and elegant language in your opinion is a language, in which solutions to every problem can be expressed by a short sequence of words, wishful only one word?

I am to admit that in D the generic type of associative arrays is present for which none of the two rules holds which I specified in the former posting. If you can transfer the principles of adding this type to your proposal I am on your side.

But now lay out, what the basic operations on the event type are. Given the declarartion `event e' how do you fill the storage, how do you call, compare, compute ...

-manfred