This print for content only-size & color not accurate 7" X 9-1/4" / casebound / malloy

// Are they considered equal when using ==?

if (firstCar == secondCar)

Console.WriteLine("Same anonymous object!");

else

Console.WriteLine("Not the same anonymous object!");

// Are these objects the same underlying type?

if (firstCar.GetType().Name == secondCar.GetType().Name)

Console.WriteLine("We are both the same type!");

else

Console.WriteLine("We are different types!");

// Show all the details.

Console.WriteLine();

ReflectOverAnonymousType(firstCar);

ReflectOverAnonymousType(secondCar);

}

C H A P T E R   1 3  

■

C #   2 0 0 8   L A N G U A G E   F E AT U R E S

443

8849CH13.qxd  10/2/07  12:42 PM  Page 443

---

Assuming you have called this method from within Main(), Figure 13-5 shows the (somewhat

surprising) output.

Figure 13-5.

The equality of anonymous types

When you run this test code, you will see that the first conditional test where you are calling

Equals() returns true, and therefore the message “Same anonymous object!” prints out to the

screen. This is because the compiler-generated Equals() method makes use of value-based

semantics when testing for equality (e.g., checking the value of each field for the objects being

compared).

However, the second conditional test (which makes use of the C# equality operator, ==) prints

out “Not the same anonymous object!”, which may seem at first glance to be a bit counterintuitive.

This is due to the fact that anonymous types do 

not receive overloaded versions of the C# equality

operators (== and !=). Given this, when you test for equality of anonymous types using the C#

equality operators (rather than the Equals() method), the references, not the values maintained by

the objects, are being tested for equality. Recall from Chapter 12 that this is the default behavior for

all class types until you overload the operators directly in your code (something that is not possible

for anonymous types, as you don’t define the type!).

Last but not least, in our final conditional test (where we are examining the underlying type

name), we find that the anonymous types are instances of the same compiler-generated class type

(in this example, <>f__AnonymousType0`3), due to the fact that firstCar and secondCar have the

same properties (Color, Make, and CurrentSpeed).

This illustrates an important but subtle point: the compiler will only generate a new class defi-

nition when an anonymous type contains 

unique names of the anonymous type. Thus, if you were

to declare identical anonymous types (again, meaning the same names) within the same assembly,

the compiler only generates a single anonymous type definition.