By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,955 Members | 1,793 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,955 IT Pros & Developers. It's quick & easy.

what is anonymas methods

P: n/a
Hi,

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

Thanks and regards.
Bhuwan
Oct 7 '07 #1
Share this Question
Share on Google+
6 Replies


P: n/a
"Bhuwan Bhaskar" <kx**@gmail.comschrieb
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

Oct 7 '07 #2

P: n/a
Hi,

"Bhuwan Bhaskar" wrote in message
news:up**************@TK2MSFTNGP03.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.
Oct 7 '07 #3

P: n/a
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

Oct 7 '07 #4

P: n/a
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

Oct 8 '07 #5

P: n/a
On Oct 8, 7:45 am, rowe_newsgroups <rowe_em...@yahoo.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 = GetCurrentCriteria();
List<Pointlist = GetSomeListOfPoints();
List<Pointresult = list.FindAll(delegate(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

Oct 8 '07 #6

P: n/a
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 = GetCurrentCriteria();
List<Pointlist = GetSomeListOfPoints();
List<Pointresult = list.FindAll(delegate(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 GetCurrentCriteria() is, we could
just use it in our predicate method (Return p.X =
GetCurrentCriteria()). But like I said, depending on the
implementation of GetCurrentCriteria() 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

Oct 9 '07 #7

This discussion thread is closed

Replies have been disabled for this discussion.