what is anonymas methods

[Bhuwan Bhaskar]

Hi,

I want to know what is anonymas methods and how they can be used.

Thanks and regards.
Bhuwan

[Armin Zingler]

"Bhuwan Bhaskar" <kx**@gmail.com schrieb

Hi,

I want to know what is anonymas methods and how they can be used.

I haven't heard of it yet. Pretty sure that it is not a term of a current or
past VB release.
Armin

[yuichiro ochifuji]

Hi,

"Bhuwan Bhaskar" wrote in message
news:up******** ******@TK2MSFTN GP03.phx.gbl...

I want to know what is anonymas methods and how they can be used.

http://msdn2.microsoft.com/en-us/lib...5k(VS.80).aspx

but C# only.

[Cor Ligthert[MVP]]

Bhuwan,

For me it is something like the overloading operator method in version 2005.

Something I never need however in my idea some want it because they cannot
make a program in a maintainable way but needs things that make their
programs "looks" more sophisticated. For others it has to be in VB.Net
because it is in C#.

Of course those things can be handy, but for me it makes only that I need
more time when I review a program of somebody else.

However just my thought,

Cor

[rowe_newsgroups]

On Oct 7, 10:55 am, "Cor Ligthert[MVP]" <notmyfirstn... @planet.nl>
wrote:

Bhuwan,

For me it is something like the overloading operator method in version 2005.

Something I never need however in my idea some want it because they cannot
make a program in a maintainable way but needs things that make their
programs "looks" more sophisticated. For others it has to be in VB.Net
because it is in C#.

Of course those things can be handy, but for me it makes only that I need
more time when I review a program of somebody else.

However just my thought,

Cor

For me, anonymous delegates have three purposes (and only one is a
good purpose).

1) Help create hard to debug and maintain code. It's sort of like
using a public field instead of a full fledged property. In the
initial release it makes things "short and sweet", but 4 months later
when you need to make a change, or reuse the function, or apply an
attribute, you must spend even more time finding and rewriting the
code to into a "proper" method.

2) Give the C# loving, VB hating people something to brag about. As
you surely know the common response to "VB can do anything C# can"
post is "Oh yeah, what about creating Anonymous Methods?" Sure we can
declare the method, but that seems to never be enough to the anti-VB
groups.

3) Limited debugging help. Often times we create a method to use
solely for debugging. Generally, these are used to check for the
existence of a problem and then deleted. In this case it's nice to
wrap everything in one method declaration instead of having multiple
methods we need to delete afterwards. After all, stranding a method
can lead to confusion during maintenance, since you probably won't
remember what the method was ever used for.

(Just some casual observations on the topic)

Thanks,

Seth Rowe

[Brian Gideon]

On Oct 8, 7:45 am, rowe_newsgroups <rowe_em...@yah oo.comwrote:

For me, anonymous delegates have three purposes (and only one is a
good purpose).

1) Help create hard to debug and maintain code. It's sort of like
using a public field instead of a full fledged property. In the
initial release it makes things "short and sweet", but 4 months later
when you need to make a change, or reuse the function, or apply an
attribute, you must spend even more time finding and rewriting the
code to into a "proper" method.

I hold the opposite view. When used appropriately it makes the code
*much* easier to read and maintain. Consider this example that
searches a List for all Point objects with the same X coordinate.

int criteria = GetCurrentCrite ria();
List<Pointlist = GetSomeListOfPo ints();
List<Pointresul t = list.FindAll(de legate(Point p) { return p.X =
criteria; });

Aside from using lambda expressions it just doesn't get any clearer
than that. The predicate logic is embedded in the same spot where it
is used. Now, consider what this would look like in VB. There are
two alternatives. The first requires creating a new instance variable
in the class whose only purpose is to temporarily store the criteria
so that it can be referenced in the Predicate delegate. The second
requires creating a brand new class that has the instance variable and
Predicate delegate. It's the better of the two options (and what the
C# compiler does for you), but still not very elegant if you ask me.

>
2) Give the C# loving, VB hating people something to brag about. As
you surely know the common response to "VB can do anything C# can"
post is "Oh yeah, what about creating Anonymous Methods?" Sure we can
declare the method, but that seems to never be enough to the anti-VB
groups.

VB.NET's lack of anonymous methods is (was) unfortunate. Lamda
expressions arrive next year though.

>
3) Limited debugging help. Often times we create a method to use
solely for debugging. Generally, these are used to check for the
existence of a problem and then deleted. In this case it's nice to
wrap everything in one method declaration instead of having multiple
methods we need to delete afterwards. After all, stranding a method
can lead to confusion during maintenance, since you probably won't
remember what the method was ever used for.

(Just some casual observations on the topic)

Thanks,

Seth Rowe

[rowe_newsgroups]

Sorry, I got quite busy yesterday and didn't get a chance to respond.

I hold the opposite view. When used appropriately it makes the code
*much* easier to read and maintain.

The key phrase here is "when used appropriately." In my experience
anonymous methods are easy to misuse, in that they are used to just to
be "lazy" putting everything in-line instead of adding an additional
method. And for the record, I never said that anonymous methods
couldn't increase readability, I just said they can make maintenance
more difficult (as it can get messy adding additional lines to a
delegate, such as code to fire off events, or attributes, or reusing
the code, et cetera).

int criteria = GetCurrentCrite ria();
List<Pointlist = GetSomeListOfPo ints();
List<Pointresul t = list.FindAll(de legate(Point p) { return p.X =
criteria; });

Very good example! I hadn't thought about the sharing of method-level
variables when I posted.

The first requires creating a new instance variable in the
class whose only purpose is to temporarily store the criteria

Well, depending on where and what GetCurrentCrite ria() is, we could
just use it in our predicate method (Return p.X =
GetCurrentCrite ria()). But like I said, depending on the
implementation of GetCurrentCrite ria() this could lead to poor
performance (as in the case of remote service calls) or to inconstant
data (if for example the method read out real-time data).

I guess the question now becomes when is the proper time to use an
anonymous method, and when is the proper time to wrap the
functionality into a full fledged method? Any more ideas besides the
local variable sharing?

Thanks,

Seth Rowe