Anonymous Methods …


I read Anonymous Methods support in Whidbey (CLR) last week and decided to play with it. This looks a lot like how Javascript (in IE) handles event -


<body onload="msgbox('hello')" ..>


In general Anonymous Methods allows code block in place of delegate. For example,


public class TestApp: Windows.Application
{
 protected override void
  
OnStartingUp(
Windows.StartingUpCancelEventArgs e)
 {
  Window win = new Window();
  win.Text = "My Avalon Window";
  win.SizeChanged +=
delegate { win.Text = "My Avalon Window changed"; };
 ...
 }


My first impressions are "how can I debug this in my IDE?" and "isn't this going to make my code messy?".


I did a test with my VS Whidbey PDC and to my suprise, it actually work with the debugging. The following line actually being called twice when my loading my Window.


 win.SizeChanged += delegate { win.Text = "My Avalon Window changed"; };


The first time to setup the SizeChanged event-handling and second (and subsequent) time when my Window's size changed.


This solves my first concern, what about the second one? I thought about it for a while, it's up to you to decide to use it or not. I think Anonymous Method is suitable for a small anonymous method (like setting 1 or 2 properties). Using Anonymous Methods will help me reduce the number of lines in code due to less Event Handlers. For event handlers that do a bunch of things, you can always use stick to using an event handler.


This posting is provided "AS IS" with no warranties, and confers no rights.

Comments (13)
  1. moo says:

    I remain unconvinced about the real usefullness of these appart from lazyness.

  2. moo says:

    I think this is bad…

    win.SizeChanged += delegate { win.Text = "My Avalon Window changed"; };

    The call to win.SizeChanged += blah means SUBSCRIBE to this event. Now what been done here is when the debugger steps to the anonymous code block, its confusing, because when i see += operators on events, i think SUBSCRIBE not do this block of code. Its bad bad bad.

  3. moo says:

    I guess the debugger will jump into a SUBSCRIBE line when infact its executing code blocks for a fired event.

    Smells of shit to me this anonymous methods.

  4. The debugger is smart enough to only highlight "win.Text = "My Avalon Window changed";" and not the entire line when debugging. Also, if you simply break the code out into a couple lines then it might be more acceptable for you.

    win.SizeChanged += delegate {

    win.Text = "My Avalon Window changed";

    };

    This of course is a simple use of anonymous methods that doesn’t provide any real power to C#, but there are some very cool ways to use this capability to enable some scenerios that weren’t possible before. Check this site for a sample of one of those uses:

    http://www.asprelated.com/csharp/sharp-19_2.aspx

  5. moo says:

    Doesnt change the fact that its still part of the subscribe construct and its just there for fat arsed lazy assed developers.

  6. moo says:

    How easy do they want it, i mean in the IDE if you hit TAB it will complete the EventHandler method block for you.

  7. Kenny Lim says:

    I’m not suggesting to use Anonymous Method to replace all your delegate. This feature is good for certain scenarios like those event handlers that have 1/2 lines in it.

    It’s all additional options for developers.

  8. moo says:

    In a direct quote from a previous blog…

    http://blogs.msdn.com/ericgu/archive/2004/02/05/68186.aspx

    "One of our design goals is not to have more than one way of doing something (in contrast to Perl’s tmtowtdi). If there are two different ways of doing something, developers need to learn both ways and understand that they are equivalent. That makes their job more complex without any real benefit."

    So, I guess this goes against those "design goals" that where ranted about earlier.

  9. moo says:

    How does one UNSUBSCRIBE (unwire) an anonymous method, we dont know the internal ID thats assigned to this so how is this possible? I think thats where it gets MESSY.

  10. moo says:

    If we cannot unwire an anonymous method, must we have to retain a state field and do an if (state == true) { doSOmething; } ?

    If we cant unwire anonymous methods, what is the freakin use of having them if theyre gona fire every time even if we dont want them.

  11. Andreas Häber says:

    moo,

    Do you really take -= on all event-handlers? Look at this small example:

    (this textbox isn’t the best editor to use, so please disregard small syntax errors ;))

    public class MyForm : Form

    {

    private Button cmdHitMe;

    private Button cmdOuch;

    public MyForm ()

    {

    // Some code to initialize the buttons and

    // place them on MyForm ommitted for clearity..

    cmdHitMe.OnClick += delegate { MessageBox ("Hello!") ; }

    cmdOuch.OnClick += delegate { cmdHitMe.Enabled = !cmdHitMe.Enabled; }

    }

    }

    In the cmdOuch.OnClick handler.. do you really think it would be better to unwire cmdHitMe.OnClick instead?

    Like other people have said before, use it if you want — and use it where it’s useful 🙂 If the OnClick methods do something more than trivial of course place it in a named method…

    I really can’t see your problem with this…?

  12. moo says:

    SO, can we unwire anonymous methods or not?

    I take your response as a NO.

  13. Andreas Häber says:

    Thanks for reading my comment without understanding it 😉 Please read it again and I hope you’ll realize that you absolutely not will use anonymous methods everywhere you have the opportunity.

    Just because it’s a new language feature doesn’t mean you _have_ to use it. Most of the events in a standard Windows Forms or ASP.NET application won’t have to be unwired manually, so that’s a perfect opportunity to use anonymous methods (if you’re gonna just do something quick in that handler…).

    But I assume you’re still not convinced that anon. methods are not the next big evil thing introduced in a language since goto…

Comments are closed.

Skip to main content