On Wed, 13 Aug 2008 03:53:02 -0700, Ben <Be*@discussions.microsoft.com>
wrote:
Yes, you're right Goran. Since C# 2.0 we can have both anonymous methods
and
delegates as return values of methods,
No, not really. Anonymous methods and delegates are two different
things. A delegate is a type. An anonymous method is just that: a method
without a name.
Warning: pedantry coming up. But it's important pedantry, IMHO.
Strictly speaking, your statement is correct. But only because you seem
to be using the phrase "return values" where you really mean "return
type". Inferring that you really mean "return type" (that is, the type of
the return value for a method), then only a delegate can be used as a
"return type of methods". A method, anonymous or names, isn't a type and
so can't be used as a type.
Conversely, if I take your statement literally, then sure...you can have
an anonymous method as a return value as well as a delegate. But they
can't be used interchangeably. An anonymous method returned from a method
would be returned as a delegate type, but a delegate returned from a
method would be returned as a Type type.
Why am I making this distinction? Because IMHO it's very important to
understand the difference between a type (delegate) and an instance of a
type (anonymous method). You wouldn't write "we can have both integer
literals and ints as return types of methods", would you?
Now, I realize that's not really the question you were asking. But it
seems to me that it's important to get the terminology straight first.
Otherwise, we might be trying to talk about some topic with each other and
completely fail to understand each other.
Bringing it back full circle, you can only have a delegate as a return
type for a method. It's true that you can instantiate the delegate with
an anonymous method, but that's not really any different from
instantiating it with a named method. The important thing here is the
returning of a delegate.
So, as far as your actual question goes...
[...] I can understand when a method
returns an int, a class, an array etc. but a function? I don't get this
simple idea of returning functionality :) When would I want to return
functionality?
Just FYI, there are a number of languages for which "returning
functionality" is essentially the main paradigm. That is, the language is
based primarily or entirely on the concept of functionality as a type.
Realizing that, hopefully that illustrates that even if one cannot
immediately see the use, you can in fact write entire programs around the
idea.
As for how it's useful in C#, I would say that it's not something that
comes up a lot. But when it does come up, it's likely to be the most
elegant way to do something.
Jon provides some abstract suggestions as to when you might want to use
it, plus one pretty esoteric concrete example (he's trying to improve a
reflection-based implementation by calling methods through the faster
delegate-based mechanism). :) Here's something that might be a little
more "real-world" (or at the very least, maybe easier to understand):
delegate object IntOperator(int i1, int i2);
Operator GetIntOperator(char chOperator)
{
switch (chOperator)
{
case '+':
return (x, y) =x + y;
case '-':
return (x, y) =x - y;
case '*':
return (x, y) =x * y;
case '/':
return (x, y) =x / y;
}
return null;
}
So, then some code parsing textual representations of expressions could
use the GetOperator() method to get an implementation of an operator based
on some character input. (This isn't necessarily the _best_ way to
implement an interpreter, but then the example would work so well
otherwise :) ).
Lamba expressions especially, but even anonymous methods, provide a nice
paradigm for representing some functional logic that you want to pass
around for use later. It can be very expressive, as compared to a more
imperative way of writing the program.
Pete
