Anonymous Methods

Anonymous Methods

In the original C# language, to construct a delegate object you have to provide it with the name of a method. The code below shows an example: ‘Print’ is first defined as a particular delegate type, then its instance ‘delegateVariable’ is created by passing it the name of the method ‘realMethod’.

1. delegate void Print (string s); 2. Print delegateVariable = new Print(realMethod); 3. 4. public void realMethod (string myString) 5. { 6.     MessageBox.Show(myString); 7. }

Now, however, C# has been updated to include ‘anonymous’ methods (which should be pretty easy for anyone who has used anonymous functions in languages like Javascript). These allow you to construct a delegate by specifying, rather than just naming a method. The following gives an example of how the above code could be written using an anonymous method:

1. public delegate void Print (string s); 2. Print delegateVariable = delegate(string myString) {MessageBox.Show(myString);};

In the above case, the anonymous method is given the same signature as the delegate it is passed to. But this is not always necessary. For the anonymous method to be acceptable, the following two conditions must be met:

1. Either the anonymous method has a parameter list that exactly matches the delegate’s parameters; or the anonymous method has no parameter list and the delegate has no ‘out’ parameters.

2. Either the values returned by the anonymous method are all of the right type for the delegate; or the anonymous method doesn’t return anything and the delegate’s return type is ‘void’.

An implication of the first condition is that an anonymous method with no parameters at all can fit a delegate with parameters. The following code is thus possible (notice that we’ve had to remove the use of ‘myString’ in the Show method, because we’re no longer passing it in):

1. public delegate void Print (string s); 2. Print delegateVariable = delegate {MessageBox.Show(“hello world!”);};

Outer Types

Anonymous methods can also make use of the local variables and parameters in whose scope the anonymous method lies. This is a somewhat complicated, and we don’t yet have a clear idea of when one should exploit it. So to illustrate it we’ll borrow the example from the documentation.

1. delegate int myDelegate(); 2. class Test 3. { 4.     static myDelegate myFunc() 5.     { 6.         int x=0; 7.         myDelegate result = delegate {return ++x;} 8.         return result; 9.     } 10.      11.     static void Main() 12.     { 13.         myDelegate d = myFunc(); 14.         Console.WriteLine(d()); 15.         Console.WriteLine(d()); 16.         Console.WriteLine(d()); 17.     } 18. }

Here the delegate ‘result’ declared in the function ‘myFunc’ makes use of (in the jargon, captures) the integer ‘x’ which is declared in the same function. Now, if we run the code, the output is this:

1
2
3

This result is somewhat surprising, since the integer ‘x’ is instantiated and its value maintained across three delegate calls after the function myFunc has finished running. How this is described in the documentation is that the lifetime of the captured outer type is ‘extended’, so that it lasts as long as any delegate that references it.

A further point to note is that in the example above each delegate is clearly referencing the same type instance. But there are situations in which local variables get initialized many times within a function, and these variables will count as different type instances. For example, in the following loop, the integer i is initialised three times, and the delegates added into the myDelegateArray will reference different variables.

1. myDelegate[] myDelegateArray = new myDelegate[3]; 2. for (int x=0; x<3; x++) 3. { 4.     int i = x; 5.     myDelegateArray[x] = delegate {return ++i}; 6. }

One question that this naturally raises is whether the multiple initialisation of i gives a performance hit, which one could avoid by declaring i outside the loop. But the documentation suggests that this isn’t the case; each new instance of i just slots neatly into the place vacated by the previous one.

Events

Events

To recap: in object-oriented languages, objects expose encapsulated functions called methods. Methods are encapsulated functions which run when they are invoked.
Sometimes, however, we think of the process of method invocation more grandly. In such a case, the method invocation is termed an 'event', and the running of the method is the 'handling' of the event. An archetypal example of an event is a user's selection of a button on a graphical user interface; this action may trigger a number of methods to 'handle' it.
What distinguishes events from other method invocations is not, however, that they must be generated externally. Any internal change in the state of a program can be used as an event. Rather, what distinguishes events is that they are backed by a particular 'subscription-notification' model. An arbitrary class must be able to 'subscribe to' (or declare its interest in) a particular event, and then receive a 'notification' (ie. have one of its methods run) whenever the event occurs.
Delegates - in particular multicast delegates - are essential in realizing this subscription-notification model. The following example describes how Class 2 subscribes to an event issued by Class 1.

1. Class 1 is an issuer of E-events. It maintains a public multicast delegate D.

2. Class 2 wants to respond to E-events with its event-handling method M. It therefore adds onto D a reference to M.

3. When Class 1 wants to issue an E-event, it calls D. This invokes all of the methods which have subscribed to the event, including M.

The 'event' keyword is used to declare a particular multicast delegate (in fact, it is usual in the literature to just identify the event with this delegate). The code below shows a class EventIssuer, which maintains an event field myEvent. We could instead have declared the event to be a property instead of a field  . To raise the myEvent event, the method onMyEvent is called (note that we are checking in this method to see if myEvent is null - trying to trigger a null event gives a run-time error).

1. public class EventIssuer 2. { 3.     public delegate void EventDelegate(object from, EventArgs args); 4.     public event EventDelegate myEvent; 5. 6.     protected virtual void onMyEvent(EventArgs args) 7.     { 8.         if (myEvent!=null) 9.             myEvent(this, args); 10.     } 11.

A class which wanted to handle the events issued by an EventIssuer ei with its method handleEvents would then subscribe to these events with the code:

ei.myEvent += new EventIssuer.EventDelegate(handleEvents);

Good Practice For Events

The code above demonstrates some points about event-handling which are not enforced by the language architecture, but are used throughout the .Net framework as good practice.
1. When you want to raise an event in code, you don't tend to trigger the class's event object directly. Rather, you call a 'protected, virtual' method to trigger it (cf. the onMyEvent method above).
2. By convention, when events are raised they pass two objects to their subscribers. The first is a reference to the class raising the event; the second is an instance of the System.EventArgs class which contains any arbitrary data about the event.
3. If an event is not interested in passing data to subscribers, then its defining delegate will still reference an EventArgs object (but a null value will be passed by the event). If an event should pass data to its subscribers, however, then it is standard to use a specific class which derives from the EventArgs class to hold this data.
4. When you write a class which inherits from an event-raising base class, you can 'intercept' an event by overriding the method used to raise it. The following code illustrates such an intercept - classes which subscribe to the event will never receive notifications about it.

1.     protected override void onMyEvent(EventArgs args) 2.     { 3.          Console.WriteLine("hello"); 4.     } 5.

If you want subscribers to continue to receive notifications despite such an 'intercepting' method, however, then you can call the base class method as in the following:

1.     protected override void onMyEvent(EventArgs args) 2.     { 3.          Console.WriteLine("hello"); 4.          base.onMyEvent(args); 5.     } 6.

DELEGATE

Delegates are reference types which allow indirect calls to methods. A delegate instance holds references to some number of methods, and by invoking the delegate one causes all of these methods to be called. The usefulness of delegates lies in the fact that the functions which invoke them are blind to the underlying methods they thereby cause to run (see, for instance, the discussion of events, below).
From this brief description, it can be seen that delegates are functionally rather similar to C++'s 'function pointers'. However, it is important to bear in mind two main differences. Firstly, delegates are reference types rather than value types. Secondly, some single delegates can reference multiple methods

Delegate Declaration and Instantiation

Delegates can be specified on their own in a namespace, or else can be specified within another class (the examples below all show the latter). In each case, the declaration specifies a new class, which inherits from System.MulticastDelegate.
Each delegate is limited to referencing methods of a particular kind only. The type is indicated by the delegate declaration - the input parameters and return type given in the delegate declaration must be shared by the methods its delegate instances reference. To illustrate this: a delegate specified as below can be used to refer only to methods which have a single String input and no return value:

public delegate void Print (String s);

Suppose, for instance, that a class contains the following method:

1. public void realMethod (String myString) 2. { 3.     // method code 4. }

Another method in this class could then instantiate the 'Print' delegate in the following way, so that it holds a reference to 'realMethod':

Print delegateVariable = new Print(realMethod);

We can note two important points about this example. Firstly, the unqualified method passed to the delegate constructor is implicitly recognised as a method of the instance passing it. That is, the code is equivalent to:

Print delegateVariable = new Print(this.realMethod);

We can, however, in the same way pass to the delegate constructor the methods of other class instances, or even static class methods. In the case of the former, the instance must exist at the time the method reference is passed. In the case of the latter (exemplified below), the class need never be instantiated.

Print delegateVariable = new Print(ExampleClass.exampleMethod);

The second thing to note about the example is that all delegates can be constructed in this fashion, to create a delegate instance which refers to a single method. However, as we noted before, some delegates - termed 'multicast delegates' - can simultaneously reference multiple methods. These delegates must - like our Print delegate - specify a 'void' return type.
One manipulates the references of multicast delegates by using addition and subtraction operators (although delegates are in fact immutable reference types ) The following code gives some examples:

1. Print s = null; 2. s = s + new Print (realMethod); 3. s += new Print (otherRealMethod);

The - and -= operators are used in the same way to remove method references from a delegate.
The following code gives an example of the use of delegates. In the Main method, the Print delegate is instantiated twice, taking different methods. These Print delegates are then passed to the Display method, which by invoking the Print delegate causes the method it holds to run. As an exercise, you could try rewriting the code to make Print a multicast delegate.

1. using System; 2. using System.IO; 3. 4. public class DelegateTest 5. { 6.     public delegate void Print (String s); 7. 8.     public static void Main() 9.     { 10.         Print s = new Print (toConsole); 11.         Print v = new Print (toFile); 12.         Display (s); 13.         Display (v); 14.     } 15. 16.     public static void toConsole (String str) 17.     { 18.         Console.WriteLine(str); 19.     } 20. 21.     public static void toFile (String s) 22.     { 23.         StreamWriter fileOut = File.CreateText("fred.txt"); 24.         fileOut.WriteLine(s); 25.         fileOut.Flush(); 26.         fileOut.Close(); 27.     } 28. 29.     public static void Display(Print pMethod) 30.     { 31.         pMethod("This should be displayed in the console"); 32.     } 33. }

METHODS

A method is a member that implements a computation or action that can be performed by an object or class. Static methods are accessed through the class. Instance methods are accessed through instances of the class.

Methods have a (possibly empty) list of parameters, which represent values or variable references passed to the method, and a return type, which specifies the type of the value computed and returned by the method. A method’s return type is void if it does not return a value.

The signature of a method must be unique in the class in which the method is declared. The signature of a method consists of the name of the method and the number, modifiers, and types of its parameters. The signature of a method does not include the return type.

Parameters

Parameters are used to pass values or variable references to methods. The parameters of a method get their actual values from the arguments that are specified when the method is invoked. There are four kinds of parameters: value parameters, reference parameters, output parameters, and parameter arrays.

Value and Reference Parameters

  You pass value-type method parameters by value—that is, you pass a copy of the value to the method. Therefore, what the called method does with the incoming parameter doesn’t affect the variable passed down from the calling method. Consider the following simple example:

Using System;

class SomeClass

{

    public int ChangeInt(int val)

    {   val = val*2;

        return val;

    }

}

class ValRefTest

{

    static void Main(string[] args)

    {

        SomeClass sc = new SomeClass();

        int val1 = 3;

        int val2 = sc.ChangeInt(val1);

        Console.WriteLine("val1 = {0}, val2 = {1}", 

            val1, val2);

    }

}

The output from this code will be:

val1 = 3, val2 = 6

The behavior with reference-type parameters is different because what gets passed is a copy of the reference (another reference to the same data). Therefore, if the called method makes changes to the data through the reference, the changes are made to the original data. The reference held by the calling method is a reference to the same data, so the changes will be available to the calling method when the called method returns:

Using System;

class SomeClass

{

    public int ChangeInt(ref int val)

    {   val = val*2;

        return val;

    }

}

class ValRefTest

{

    static void Main(string[] args)

    {

        SomeClass sc = new SomeClass();

        int val1 = 3;

        int val2 = sc.ChangeInt(ref val1);

        Console.WriteLine("val1 = {0}, val2 = {1}", 

            val1, val2);

    }

}

The output from this code will be:

val1 = 6, val2 = 6

Let’s be clear about this process: in both cases, a copy of the parameter passes from caller to called method. If you pass a copy of a value type, you get a copy of the data. But if you pass a copy of a reference type, you get a copy of the reference. When accessing the original data, a copy of a reference is indistinguishable from the original reference.

Using out Access to Parameters

The return type enables you to send back a single variable from a method; however, sometimes you will want more than one value to be returned. Although reference variables could be used to do this, C# has also added a special attribute type specifically for returning data from a method.

You can add parameters to your method header specifically for returning values by adding the out keyword. This keyword signifies that a value is being returned out of the method but is not coming in. When you call a method that has an out parameter, you must be sure to include a variable to hold the value being returned.

using System;

 class nbr

 {

 public void math_routines( double x, out double half, out double squared,

            out double cubed )

            {

                        half = x / 2;

                        squared = x * x;

 cubed = x * x * x;

 }

 }

 class Outter

 {

            public static void Main()

 {

                        nbr doit = new nbr();

                        double nbr = 600;

 double Half_nbr, Squared_nbr Cubed_nbr;

           

 doit.math_routines( nbr, out Half_nbr,

 out Squared_nbr, out Cubed_nbr );

                        Console.WriteLine(“After method -> nbr = {0}”, nbr);

 Console.WriteLine(“ Half_nbr = {0}”, Half_nbr);

 Console.WriteLine(“ Squared_nbr = {0}”, Squared_nbr);

 Console.WriteLine(“ Cubed_nbr = {0}”, Cubed_nbr);

 }

 }

Output of the program is-

After method -> nbr = 600

Half_nbr = 300

Squared_nbr = 360000

Cubed_nbr = 216000000

Variable Number of parameters

A parameter array permits a variable number of arguments to be passed to a method. A parameter array is declared with the params modifier. Only the last parameter of a method can be a parameter array, and the type of a parameter array must be a single-dimensional array type.

The Write and WriteLine methods of the System.Console class are good examples of parameter array usage. They are declared as follows.

public class Console
{
            public static void Write(string fmt, params object[] args) {...}

            public static void WriteLine(string fmt, params object[] args) {...}

            ...
}

Within a method that uses a parameter array, the parameter array behaves exactly like a regular parameter of an array type. However, in an invocation of a method with a parameter array, it is possible to pass either a single argument of the parameter array type or any number of arguments of the element type of the parameter array. In the latter case, an array instance is automatically created and initialized with the given arguments. This example

Console.WriteLine("x={0} y={1} z={2}", x, y, z);

is equivalent to writing the following.

object[] args = new object[3];
args[0] = x;
args[1] = y;
args[2] = z;
Console.WriteLine("x={0} y={1} z={2}", args);

For instance, the example

using System;

class Test

 {

 static void F(params int[] args) {

 Console.WriteLine("# of arguments: {0}", args.Length);

 for (int i = 0; i < args.Length; i++)

 Console.WriteLine("\targs[{0}] = {1}", i, args[i]);

 }

 static void Main() {

 F();

 F(1);

 F(1, 2);

 F(1, 2, 3);

 F(new int[] {1, 2, 3, 4});

 }

 }

 shows a method F that takes a variable number of int arguments, and several invocations of this method.

 The output is:

 # of arguments: 0

 # of arguments: 1

 args[0] = 1

 # of arguments: 2

 args[0] = 1

 args[1] = 2

 # of arguments: 3

 args[0] = 1

 args[1] = 2

 args[2] = 3

 # of arguments: 4

 args[0] = 1

 args[1] = 2

 args[2] = 3

 args[3] = 4