An idea came to my mind. D allows operators to be applied to the entire array, so, for example, foo[]++ should be equal to:

    for (uint i = 0; i < foo.length; i++)
        foo[i]++;

Now, if we just think of () as of "call delegate" operator (and obviously
it is), then foo[]() should be treated as:

    for (uint i = 0; i < foo.length; i++)
        foo[i]();

Seems logical, doesn't it? And makes it easy to have arrays of delegates without clumsy wrappers:

    void delegate(int x, int y)[] onMouseMove;
    void mouseMoved(int x, int y) { onMouseMove[](x, y); }    // call 'em
all!

    wnd.onMouseMove ~= &handler1;
    wnd.onMouseMove ~= &handler2;
    ...

Thus beating C# into dust! =)

Great thinking, Pavel!!!

--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

That is a neat idea.

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a9bpa5$12pe$1@digitaldaemon.com...
> An idea came to my mind. D allows operators to be applied to the entire array, so, for example, foo[]++ should be equal to:
>
>     for (uint i = 0; i < foo.length; i++)
>         foo[i]++;
>
> Now, if we just think of () as of "call delegate" operator (and obviously
> it is), then foo[]() should be treated as:
>
>     for (uint i = 0; i < foo.length; i++)
>         foo[i]();
>
> Seems logical, doesn't it? And makes it easy to have arrays of delegates without clumsy wrappers:
>
>     void delegate(int x, int y)[] onMouseMove;
>     void mouseMoved(int x, int y) { onMouseMove[](x, y); }    // call 'em
> all!
>
>     wnd.onMouseMove ~= &handler1;
>     wnd.onMouseMove ~= &handler2;
>     ...
>
> Thus beating C# into dust! =)
>
>

"Pavel Minayev" <evilone@omen.ru> wrote in news:a9bpa5$12pe$1@digitaldaemon.com:

> Now, if we just think of () as of "call delegate" operator (and
> obviously it is), then foo[]() should be treated as:
> 
>     for (uint i = 0; i < foo.length; i++)
>         foo[i]();
> 

Can we apply this to arrays of objects too?

class Foo
{
  void Bar()
  {
  }
  void Fred()
  {
  }
}

Foo[] arr;

arr[].Bar(); // ??


Or perhaps...

with(arr[])
{
  Bar();
  Fred();
}

Suddenly, when we least expect it, we have a convenient syntax for "foreach" constructs. :)

Of course, we can't use the return code from it (unless all of the return codes are packed into an array the same length as arr[]

Nor is it totally clear what happens during exceptions.  Perhaps we need a meta-variable that would tell us which index we were working on when the exception was thrown?

--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

Russ Lewis <spamhole-2001-07-16@deming-os.org> wrote in news:3CBA03E6.BF5DB7FD@deming-os.org:

> Suddenly, when we least expect it, we have a convenient syntax for "foreach" constructs. :)
> 
> Of course, we can't use the return code from it (unless all of the return codes are packed into an array the same length as arr[]
> 

Actually I see no reason why this shouldn't work.

int[] a;
Foo[] b;

a[] = b[].Bar();

Patrick Down wrote:

> Russ Lewis <spamhole-2001-07-16@deming-os.org> wrote in news:3CBA03E6.BF5DB7FD@deming-os.org:
>
> > Suddenly, when we least expect it, we have a convenient syntax for "foreach" constructs. :)
> >
> > Of course, we can't use the return code from it (unless all of the return codes are packed into an array the same length as arr[]
> >
>
> Actually I see no reason why this shouldn't work.
>
> int[] a;
> Foo[] b;
>
> a[] = b[].Bar();

There would also have to be a spec on how to do arguments.  Consider:

    int Fred();
    b[].Baz(Fred());

does this expand to:
    for(int i=0; i<b.length; i++) b[i].Baz(Fred());
or
    {
        int temp = Fred();
        for(int i=0; i<b.length; i++) b[i].Baz(temp);
    }
The difference could be very significant if Fred() actually did
something (some side effect), or if Fred() had a long running time.

I would argue for the latter, but would be very uncomfortable with it if the community didn't generally agree that that was the "right" (i.e. the anticipated) spec.  Few things are worse than having something you *think* works one way, but works the opposite...

--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

Russ Lewis <spamhole-2001-07-16@deming-os.org> wrote in news:3CBA6047.B188929@deming-os.org:

> Patrick Down wrote:
> 
>> Russ Lewis <spamhole-2001-07-16@deming-os.org> wrote in news:3CBA03E6.BF5DB7FD@deming-os.org:
>>
>> > Suddenly, when we least expect it, we have a convenient syntax for "foreach" constructs. :)
>> >
>> > Of course, we can't use the return code from it (unless all of the
> There would also have to be a spec on how to do arguments.  Consider:
> 
>     int Fred();
>     b[].Baz(Fred());
> 
> does this expand to:
>     for(int i=0; i<b.length; i++) b[i].Baz(Fred());
> or
>     {
>         int temp = Fred();
>         for(int i=0; i<b.length; i++) b[i].Baz(temp);
>     }
> The difference could be very significant if Fred() actually did
> something (some side effect), or if Fred() had a long running time.
> 
> I would argue for the latter, but would be very uncomfortable with it if the community didn't generally agree that that was the "right" (i.e. the anticipated) spec.  Few things are worse than having something you *think* works one way, but works the opposite...
> 

I would argue for the former. :)  If you adopt this method then the latter example can always be constructed like this...

int temp = Fred();
b[].Baz(temp)

but it's impossible to go the other way without explictily making the loop.

"Patrick Down" <pat@codemoon.com> wrote in message news:Xns91F1EBD9CDFFpatcodemooncom@63.105.9.61...

> I would argue for the former. :)  If you adopt this method then the latter example can always be constructed like this...
>
> int temp = Fred();
> b[].Baz(temp)
>
> but it's impossible to go the other way without explictily making the loop.

Where you want a loop, it's better to state it clearly by making a loop. However, when you write:

    b[].baz(fred());

You only see fred() once in the expression, so, IMO, it should
be evaluated only once.

Actually, this is exactly the behavior you get from C# when using the
"event" keyword.  See thread "More on Delegats" (in "D alpha 26") for sample
code comparision between C# and D.  Your proposal would make the D version
of Fire_MyEvent() look almost identical to the C# version:
      void Fire_MyEvent(int event_data) {
            for (int i=0; i<MyEvent.length; i++)
            {
                dg_t e = MyEvent[i];
                e(event_data);
            }
becomes
      void Fire_MyEvent(int event_data) {
            MyEvent[](event_data)
      }
which is virtually identical to the C# version
        public void Fire_MyEvent(int event_data) {
            MyEvent(event_data);
        }

   Dan

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a9bpa5$12pe$1@digitaldaemon.com...
> An idea came to my mind. D allows operators to be applied to the entire array, so, for example, foo[]++ should be equal to:
>
>     for (uint i = 0; i < foo.length; i++)
>         foo[i]++;
>
> Now, if we just think of () as of "call delegate" operator (and obviously
> it is), then foo[]() should be treated as:
>
>     for (uint i = 0; i < foo.length; i++)
>         foo[i]();
>
> Seems logical, doesn't it? And makes it easy to have arrays of delegates without clumsy wrappers:
>
>     void delegate(int x, int y)[] onMouseMove;
>     void mouseMoved(int x, int y) { onMouseMove[](x, y); }    // call 'em
> all!
>
>     wnd.onMouseMove ~= &handler1;
>     wnd.onMouseMove ~= &handler2;
>     ...
>
> Thus beating C# into dust! =)
>
>