Next generation iteration: Array.ForEach and Delegate inference

My blog has moved. You can view this post at the following address: http://www.osherove.com/blog/2004/12/30/next-generation-iteration-arrayforeach-and-delegate-inferenc.html
Published Thursday, December 30, 2004 8:46 AM by RoyOsherove
Filed under:

Comments

Wednesday, December 29, 2004 11:35 PM by TrackBack

# I wanna go too!!

Thursday, December 30, 2004 2:05 AM by Zknet

# re: Next generation iteration: Array.ForEach and Delegate inference

I think to be more perl-ish, it needs more random punctuation characters. ;)

Seriously though, I haven't been paying too much attention to .NET 2.0, so I just find that friggin' cool.
Thursday, December 30, 2004 2:21 AM by TrackBack

# Next generation iteration: Array.ForEach and Delegate inference (from: Roy Osherove)

Thursday, December 30, 2004 2:43 AM by Chris Martin

# re: Next generation iteration: Array.ForEach and Delegate inference

I think it's lame. ;)
Thursday, December 30, 2004 4:30 AM by Johan Normén

# re: Next generation iteration: Array.ForEach and Delegate inference

Reminds me a little about the Visitor Pattern.

Best,
Johan
Thursday, December 30, 2004 5:17 AM by Sean Malloy

# re: Next generation iteration: Array.ForEach and Delegate inference

IMO, I think it would have been nicer if the ForEach method was an instance method on Array.
Person[] people = new Person[]{..};
people.Each(delegate(Person p)
{
//do something
});

I guess it really doesn't matter, seeing as you can't modify the base classes anyway ;)

And yeah, I realise that on the generic List, the ForEach type methods are available.
Thursday, December 30, 2004 5:56 AM by Damien Guard

# re: Next generation iteration: Array.ForEach and Delegate inference

I'm probably missing something, how is that any improvement on the .NET 1.x syntax:

Person[] MyArray = new Person[]{..};

foreach(Person p in MyArray) MyFunction(p)

private void MyFunction(Person p)
{
//do something
}

[)amien
Thursday, December 30, 2004 8:18 AM by Roy Osherove

# re: Next generation iteration: Array.ForEach and Delegate inference

Damien: the point is that, using generics , delegate inference and the new functions, you never have to write the same logical loop twice.
You could easily write a logical loop that traverses an array of anything, which will be totally type safe, and just call array.foreach from anywhere you want on it, not duplicating the loop, and not having to use interfaces.

for example:
Array.ForEach(persons,MyFunction<Person>);
Array.ForEach(Tables,MyFunction<Table>);
and of course, having a function that dynamically calls anothe is now much easier to read and write.
Thursday, December 30, 2004 9:15 AM by Darrell

# re: Next generation iteration: Array.ForEach and Delegate inference

Actual pointers to functions are extremely easy in Python as well. He might not even need the list. Yes, Python is my new new language. :)
Friday, December 31, 2004 3:03 PM by cleverguy25@hotmail.com

# Re: Next generation iteration: Array.ForEach and Delegate inference

Because the compiler is infering a delegate for you, doesnt this mean there will be a slight perf hit over just foreach'ing over then and calling a function? That also seems more readable to me than the ForEach syntax. I think this ForEach method is more useful with anonymous delegates so that you get access to local variables...
Saturday, January 01, 2005 5:11 PM by Roy Osherove

# re: Next generation iteration: Array.ForEach and Delegate inference

Cleverguy: The compiler does this at build time, not run-time. There's no performance penatly for doing this.
Sunday, January 02, 2005 11:26 PM by Sriram

# re: Next generation iteration: Array.ForEach and Delegate inference

Actually, writing my blog post,I stumbled upon another interesting problem - that there is no way to pass *any* function.

Imagine this scenario - you take a function in a parametr. If it takes one parameter, you do something. If it takes 2 arguments, you do something else.

Stuff like this is not really possible with all this type-checking.

And this is not quite Perl-ish. These are functional programming paradigms - originally from Lisp's mapcar