Today, we’ll keep looking at generics and we’ll see how type inference is used to simplify the code we need to write to invoke a method. Lets start with a simple example:

The good news is that the MS team added generic type arguments inference. In practice, this means that we can simply call the method *without* explicitly specifying its type arguments:

Now, there’s one important detail which might get you by surprise…Take a look at the following snippet:

What will appear in the console now? If you’re thinking that the type will be System.Int32 like in the previous snippet, you’re wrong. You see, the compiler uses the variable’s data type (instead of the actual type of the object referred by that variable) when it has to infer the generic argument type. Another interesting aspect of using generics with methods is trying to understand how thing works with overloads. What should happen when the compiler finds these method overloads:

Yes, it does compile…but how does the compiler find the correct method for each of the following calls:

As you can see, the compiler will always choose a more specific call over a generic match (and that’s why the first method ends up being invoked for the first call). Notice also that when you explicitly specify the generic type argument, then the compiler is obliged to call the generic method.

And I guess that’s all for now. Stay tuned for more.

Just a quick post to let you know that this blog is moving into a new URL. If you follow my posts through the feedburner RSS link, then you won’t need to do anything because I’ll be updating that link in the  next days after moving the complete content of my blog over the new Wordpress site.

Well, the Special One has done it again…and this time, his acceptance speech was in Portuguese. Thanks and congrats.

Properties are one type of the members you can define in a class. It might seem strange, but a property will only allow us to call a method in a simplified way. In other words, you can see them as sugar for invoking methods (which typically interact with a  private field). Nonetheless, they’re important and most programming languages offer first class support for them (including C# and VB.NET). The CLR allow us to define two types of properties: parameterless and parameterful properties. In this post, we’ll concentrate in parameterless properties (and we’ll leave parameterfull properties for a future post). So, let’s get started…

As you know, most objects have state and that state is saved through instance fields. For instance, if we think about a Student class which has info about the name and address of someone, then we’d probably end up building a class which looks like this:

And then, you could consume it like this:

There’s nothing wrong with the previous code. However, there are a couple of observations that might prevent you from using the code as-is:

• Many argue that exposing fields is not a good idea because it violates one of the tenets of OO programming (data encapsulation).
• There are times where you might need to validate the values that are being set to a field. Publicly exposing a field means that anyone can set that field to any value and there’s nothing you can do about it.

The solution to this problem is simple: make you fields private and add a couple of methods which allow you to get or set the values of those fields:

And then, you’d need to change the consuming code so that it uses to methods to interact indirectly with the fields:

This new approach solves the previous problems, but it will also make you write more code and you’ll need to use the new “access” methods for interacting with the fields. Since Microsoft saw these disadvantages as problems, they’ve ended up introducing the concept of (parameterless) property. Here’s a new version of our class that relies in properties:

And here are the changes made to the consuming code:

(Notice that all these snippets end up printing the same results.)

Defining a property is simple: you can specify a get and a set method, which encapsulate the code for reading and setting the value of that property. As you might expect, get and set are both optional (though you do need to define at least a set or a get when defining a new non-abstract property): it all depends on whether you intend to allow read (get) or write (set) access to a specific property. You’ve surely noticed the use of the value parameter from within the set method. This parameter passes the value attributed to the property and, in the previous example, was simply copied into the private backing field of the property.

Even though it’s not mandatory, most properties end up manipulating one or more private fields of the class where they’re defined. When that happens, the property is said to have a backing field. So, adding a property in C# results in adding a pair of (get and set) accessor methods (depends on whether you want to allow read and write access in your property definition) and on adding a property definition to that class’ metadata. The getter and setters introduced in the property text definition are transformed into methods (prefixed with the get_ or set_ word) which are invoked whenever you read or write a value into that property. Notice that the CLR relies only in these methods for accessing the property and performing the “current” operation. Nonetheless, other tools can access the metadata information for getting more information about the members of a specific class.

When we’re creating simple read/write properties like the ones presented in the previous example, then we can reduce the amount of typing by relying in automatic properties. Here’s the revised version of our class that uses this type of properties for introducing the Name and Address properties:

Whenever you create a new property and don’t define the body of the get and set methods, the compiler will automatically introduce a backing field and will implement those acessor methods for you. These methods will simply return the value of the backing field (get) or update its value to a new one (set).

Notice that creating an automatic property is not the same thing as adding a field. With properties, the calling code will always be redirected to the get or set method (instead of accessing the field directly). The advantage of using automatic properties is that you can change the implementation of the property in the future (for instance, you might need to add validation to the values passed to the set method) and you won’t have to recompile the consuming code (if it’s in a different assembly).

There are some disadvantages regarding the use of automatic implemented properties. For starters, you cannot initialize an automatic property during its declaration (this means you need to put that initialization code into a constructor). Its use is discourage if you’re performing any serialization/deserialization of that class because you have no control over the name of the backing field and that is what gets serialized. Finally, you should keep in mind that when creating this type of property in C#, you’ll need to define a get and a set method (after all, what would be the use of having an automatic property with only a setter if you have no way to retrieve the value?)

And that’s it for now. Stay tuned for more on properties…

Happy New Year to everyone! After a small vacation period, I’m back :)

Now that the HTML book has gone to revision (more about that in future posts), I guess it’s time to start posting some useful tips in this blog. One of my new year’s resolution is to pay much more attention to JavaScript and that’s why I’ve chose this topic for this year’s first post. If you’ve been reading my blog, you’ll probably recall an old post where I advert for the possibility that anyone can redefine the global undefined and NaN variables. Since this might end up producing some very undesirable effects, I’m really happy to find out that ECMAScript 5 (ie, the JavaScript specification) has forbidden this type of information.

To be more precise, the value properties Nan, Infinity and undefined introduced by the Global Object can’t be changed or configured, nor can they be enumerated in a for–in enumeration. What does that mean? Take a look at the following sample:

Now, if you run the previous code in IE9 or in FF 4 (or even in Safari 5), you’ll end up getting the string undefined twice. Notice that you don’t end up getting an exception. You won’t simply be able to change the value…it’s as if you never run the undefined assignment…

Unfortunately, not all browsers are compatible with this new behavior, but I’m thinking that it won’t take long until all of them are compatible with the specs. And that’s it for now. Stay tuned for more  JavaScript posts.

So, it’s time to wish a Merry Christmas and a Happy New Year!

In the previous two posts, I’ve presented the basics (and some gotchas) associated with the way you declare events. In this post, I’ll present an alternative way for exposing events which is useful when you’re creating a class which has lots of events. In order to understand how this strategy works, we need to make a small detour and see what the compiler does when it finds an event field. Here’s the code we’ve been using for exposing the StudentNameChanged event:

Whenever the compiler finds this definition, it ends up generating the following code (ripped with .NET Reflector from the compiled assembly ):

At first sight, the code might look more complex than it really is. As you can see, an event is transformed into a delegate field and the event property ends up generating two methods (add and remove – btw, in the end, don’t forget that you’ll get two methods named add_StudentNameChanged and remove_StudentNameChanged). The add method is used for subscribing an event, while the remove method is called for cancelling a previous subscription. In order to ensure proper working, the code generated for the add and remove methods rely on the CompareExchange method to solve the problems that might arise when our class is used in a multithreaded application (note: the goto label shown can be seen as a do-while loop which keeps adding the passed in delegate until it succeeds in multithreaded environments). Besides that, you’ll surely notice the use of the Combine and Remove static methods used for adding and removing event handlers (I’ll also have a couple of posts about delegates, so I won’t get into this right now).

Now that we know what happens when we define an event, we can see how we can improve our previous event definition by replacing it with an explicit event implementation where the add and remove methods are explicitly defined. Before showing this, it’s important to understand why we need to use a more efficient approach for classes that expose lots of events. The best way to understand why we need this strategy is to think about classes that wrap GUI controls. If you look at the Control class, you’ll notice that it exposes lots and lots of events. If that class exposed its events by using the first approach, we’d end up with lots and lots of fields and that means a lot of memory (for events which might not even be handled by the dev that is using a control).

To solve this memory usage problem, we need to expose events in a more efficient way. To achieve this, we need to add a custom dictionary to our class and then implement our events explicitly through the add and remove methods. Here’s some code that shows how to do this:

As you can see, we’ve added a couple of fields to our class. Besides the EventHandlerList instance, I’ve also added an object used as a key for identifying the StudentNameChanged event in the events custom dictionary (_events field) and another object used for locking purposes (to ensure proper usage of our class in a multithreading environment). Btw, I’ve ended up using the EventHandlerList class since it’s used for all major UI classes introduced by the .NET framework. If you want, you can build your own custom dictionary which takes care of all the goo related with multithreading and invoking the delegates that handle the event (I’ll leave that for you as an exercise).

And I guess this sums it up quite nicely. There might still be a couple of things to say about events, but I think that these last three posts cover most of the important details nicely, so I’ll end up this series here. However, there’s sill a lot of things to talk about .NET and the CLR, so stay tuned for more.

In one of the previous posts, we’ve looked at the basics associated with .NET events. As promised, we’ll start improving our initial code and today we’ll talk about two topics:

1. lambdas aren’t always your friends.
2. we live in a multithreaded world.

Lets start with number 1…In the previous code, I’ve uses something like this to handle the event:

Before going on, you should know that I do use this approach in 90% of the scenarios. The problem with it is that you cannot cancel a previous subscription by using this approach. Here’s some code which I’ve seen people use in the past:

The idea of the previous code is simple (though utterly wrong): we subscribe an event through a lambda and then we cancel it by passing the same lambda expression. Well, the problem is that the second lambda expression is different from the first. In this case, the easiest approach is to create a method compatible with the event’s type and then use that to subscribe/cancel the event handler:

And then, we can simply subscribe/cancel the event like we did in the old days:

With 1 tackled, lets proceed to 2. It’s safe to assume that multithreading is here to stay and that means writing safer code. Let’s recover the code we used to fire the event:

Everyone who has had to write multithreaded programs will automatically cringe while reading the previous code. The problem is that between the test and the event execution, the thread can be stopped while another thread removes the existing delegate chain from the event field. And that’s why you’ll typically see the previous code re-written like this:

The idea is simple: since StudentNameChanged is copied into aux, aux will always reference the same delegate chain that existed at the time of the copy. From that point on, we’ll be using aux for testing and firing the event and we can be sure the aux’s value won’t changed between the test and the execution. Since delegates are immutable, then we’re safe, right?

Unfortunately, we’re not…I’ve used similar code to this for a long time until I’ve learnt that the compiler may optimize (though it currently doesn’t do it) the previous code and simply drop the aux reference. When that happens, we end up with the initial code which exhibits the racing behavior I’ve mentioned before. Bottom line, we need safer code. In these scenarios, the best option I’ve seen is presented by the excellent CLR via C#, by Jeffrey Richter, and consists on using the CompareExchange method:

In the previous snippet, CompareExchange will only change the StudentNameChanged event to null *when* it’s null (in other words, it will never change its value if that value is not null). The advantage of using this method is that it will always return a reference to the StudentNameChanged event in a thread safe way. With this small performance hit (yep, there’s a small cost associated with using this method), we’re really safe. As I’ve said before, the compiler doesn’t currently perform the optimization which might break our second version of the code, so you might keep using that approach. Anyway, if you’re writing long-lived code, then you probably should play it safe and go with the more robust version.

In the next post, we’ll still keep looking at events and see how we can improve event declaration for classes that expose lots of events.

Better late, than never, right? I’m happy to announce that my Silverlight book’s code is (finally) online. If you’ve bought the book, then you can head to FCA’s site and download it from the book’s page. Sorry for the delay…

I guess we all know about events, right? Even so, I’ve decided to write a couple of posts about it and today I’ll be talking about some basic stuff associated with event definition and usage. So, what is an event? An event allows a type to notify other objects about something special which happened. If you’re a .NET developer, you know that events are everywhere. For instance, if you look at the Windows Forms’ controls, you’ll see events everywhere (ex.: who hasn’t handled the Click event generated by a Button?).

When a type exposes an event, it means that:

• it allows another type to register a method which receives future notifications.
• it allows another type to cancel a previous subscription.
• it is responsible for notifying all the previous registered methods.

The CLR event model is based on delegates (which allows you to call methods in a type safe way – I guess I’ll return do delegates in future posts). Lets start with a simple example which assumes we have a simple Student type which generates an event in response to a change of its Name property (I’ll call it StudentNameChanges event). Do notice that in the real world I’d simply implement the INotifyPropertyChanged interface to signal this change. Since I want to present all the steps associated with creating an event, I’ll go with my own custom event…

When we expose an event, you must start by deciding if you’ll need to pass custom data to the methods that handle the event. In this case, I’ve decided to pass the old and new name values. In practice, this means that I’ll need to create a new type, derived from EventArgs (this is a convention), which exposes two properties: OldName and NewName.

As I’ve said, using EventArgs as base is only a convention which you should follow. Nothing prevents you from passing a non-EventArgs type to a method that handles an event (though you’re probably going against what’s expected, which is not a good thing). Now, we’re ready to define the event member. The easies way to do this is to add a public field to our class:

As you can see, an event is always declared through the event keyword, followed by the expected delegate type. In this case, and since our event args class inherits from EventArgs, we can reuse the EventHandler<T> type. After adding the field, it’s also expected to find a virtual protected method which is responsible for firing the event. Here’s the class’ complete code:

The OnNameChanged method starts by checking the StudentNameChanged event field. When it’s not null, it will call all interested parties by passing a reference to the Student instance responsible for the event and the custom EventArgs parameter it received. The previous snippet also shows how the event gets generated. As you can see, it will always be generated from the setter of the Name property.

Now, let’s see how we can consume this event from our C# code:

Experienced developers will probably detect several things which can be improved in our previous snippets. For instance, using lambda expressions are great, but only  if you don’t need to cancel the subscription. Anyway, I’ll leave this improvements to the next post of the series. Stay tuned for more.

Yep, I’ve already decided: I’ll be writing an intro book on HTML 5 (in Portuguese, of course). YEs, I just couldn’t resist it: ) I think HTML 5 is such a cool platform that I could resist writing a small book about it. But this time, I want to try something new: I want to see if anyone is interested in helping me out with the technical review.

Before going on, a couple of words about this project: I intend to write an intro book about HTML 5 and I do intend to talk about most of the new features which are associated with the HTML 5 acronym (ex.: canvas, geo-location, worker threads, etc.). It won’t be a big book (I’ll be trying to hit the 200 page mark) and  the only thing you need to do is read and give me feedback about the draft. You do not have to be an expert to be a reviewer (but if you are, you’re welcome too ). Unfortunately, there’s no money and the only thing I can promise is a special thanks entry in the acknowledgements section and a free book delivered at your home when it gets released. Not sure if this is incentive enough, but you do get the chance to bash my writing and I’ll even thank you for that.

So, if you understand Portuguese and you’re interested in helping me, please send me an email to  labreu_at_gmail.com (just replace the _at_ with the traditional @) with the subject Livro HTML and a few lines telling me why you’re interested in being a reviewer. thank you!

A few years ago, I’ve written a couple of helper classes for printing labels for those funny Zebra printers. At the time, I’ve targeted the TLP2844 model, but the code should work with any printer which understands EPL2. There was a problem with my ISP provider  which resulted in a delete of the rar file which had the code. I’ve improved the code over time, and I do intend to publish a revised version (though you’ll have to wait at least a few weeks for that). Anyway, for now I’m just putting the old version online again. You can get it from here. Enjoy :)

C# 4.0 introduced a new type whose main job is to simplify our job when writing code that needs to use reflection. I’m talking about the new dynamic type. As we all know, C# is type-safe programming language. In practice, this means that the compiler must resolve all expressions into types and their respective operations. Whenever the compiler detects an invalid operation (ex.: calling a method not exposed by a class), it must stop the compilation process and generate an error. The good news is that this type safety ensures that most (if not all) programmer’s errors are detected at compile time.

Compare this with what happens with other dynamic languages, like JavaScript. Before going on, a disclaimer: I love JavaScript, so any errors you might end up having while writing code in it can only be attributed to the developer writing it :) Anyway, how many times have we written JS code only to find out some misspelling error at runtime?

Now, there’s also advantages associated with dynamic languages. For instance, compare the code you need to write for using COM components from C# with the code you have to write to consume them from, say, JavaScript…yep, C# starts to suck when you need to do that. With the new dynamic type, things get better:) Here’s an example of what I mean:

Now, if you’re an experienced C# dev, you can’t stop noticing the simplicity of the new code. Just for the fun, let’s see the C# 3.0 equivalent code:

And I was lucky because I picked an easy method. If I needed to replace text, things would quickly become  even more boring…It’s safe to say that we all prefer version 1 of the previous example, right? And the good news is that you can use the same strategy when writing reflection code (for an example of it, check this old post).

So, what happens when you mark a variable or expression with the dynamic keyword? Whenever the compiler sees a dynamic expression, it will insert special code for describing that operation which is used at runtime to determine the real operation that needs to be performed.This special code is generated by the runtime binder. In C#, the runtime binder is defined in the Microsft.CSharp assembly and you must reference it whenever you use the dynamic keyword in your code.

At runtime, things get rather complicated because the binder ends up consuming more memory that would have been necessary if you’re using, say, reflection (if you’re using dynamic types only on a small portion of your code, then you probably should consider not using dynamic types since the advantages of dynamic might not pay off).

A dynamic operation is resolved at runtime according to the real type of the object. If that object implements the IDynamicMetaObjectProvider interface, its GetMetaObject method ends up being called. It returns a DynamicMetaObject derived type which is responsible for performing the bindings for members of that type (ie, mapping the members, methods and operators specified in the code you’ve written. Dynamic languages in .NET have their own DynamicMetaObject derived classes (which allows them to be easily consumed from C#). Something similar happens with COM components (the C# runtime binder uses a DynamicMetaObject derived object which knows how to communicate with COM components). When the object doesn’t implement the interface, C# ends up using reflection for executing the required operations.

Now, there are a couple of interesting operations you can do with a dynamic type. For starters, any expression can be implicitly converted into a dynamic type:

Yep, you’ll end up with boxing in the previous snippet. Even more interesting is the fact that you can implicitly convert from a dynamic into some other type because the CLR will validate that cast at runtime:

Notice that you cannot do this with an Object instance that resulted from boxing an integer. If the dynamic value isn’t compatible with the desired type, you’ll end up with a InvalidCastException. Another interesting thing is that evaluating a dynamic expression gives you a new dynamic expression:

You’ll succeed if you try to compile the previous snippet! Of course, you’ll get an exception at runtime since ints don’t have a DoesntHaveThisMethodButCompiles method. Notice that var is the same as dynamic in the previous snippet! (and, btw, don’t confuse var with dynamic. var is just a shortcut that lets the compiler infer the type of a variable).

Whenever you use a dynamic variable in a foreach or using block, the compiler will automatically generate the correct code for that scenario (in the foreach, it will convert the variable into an IEnumerable; in the using case, it will cast it to IDisposable). Pretty slick, right?

And that’s it. Stay tuned for more.

In the previous post, we’ve started looking at the Equals method and saw that its default implementation (inherit from Object) had some flaws. We’ve seen a better implementation for it and we’ve also talked about some strategies for overriding the method in new custom types. In this post, we’re going to talk about a somewhat related concept: hash codes.

You see, all objects inherit a method called GetHashCode from the base Object type. This method is virtual, returns an integer and is defined by the Object type because the designers of the framework though that it would be a good idea to allow any object to be used as a key in a hashtable. The current rules governing hash code generation are quite interesting:

• if two objects *are* equal, then they should return the *same* hash code.
• if two objects *aren’t* equal, they don’t have to generate *different* hash codes. Many are surprised by this at first…
• you should use at least one instance field for calculating the hash code of an object. You should rely on immutable fields for this because these fields are initialized during construction and then remain constant during the object’s lifetime. This is important and the docs should have presented this a a *must* (not a *should*).
• the returned result must be consistent and it should be the same as long as there is no modification to the object state that determines the return value of the Equals method.
• your method should strive to have a good random distribution.

As you can see, the rules for hash code generation imply that you’ll have to override GetHashCode whenever you override the Equals method. The Object’s GetHashCode implementation inherited by all types will simply return a number which doesn’t change during the object’s lifetime and is guaranteed to uniquely identify it in the current application domain. As you might expect, ValueType does follow the previous rules while overriding the GetHashCode method. Unfortunately, you’ll have the same performance problem mentioned before because it will have to use reflection to ensure that all the fields of a type are used in the algorithm.

Building your own hash code method isn’t as easy as it might look at first. If you look at the previous rules, you’ll notice that there are several constraints which make it hard to implement. One of the things that isn’t mentioned in the previous list (and it should be!) is that hash codes shouldn’t be able to change. In fact, they *can’t* change because it might break your application. Unfortunately, this isn’t really mentioned in the docs nor followed by the framework code. A quick example is the best way of illustrating this point. Take a look at the following code:

This code seems simple enough and harmless, right? Well, guess what? It’s not…one of the things you should keep in mind while creating new value types is that they should be immutable! For instance, take a look at the DateTime struct…you’ll quickly notice that it doesn’t have any write properties and none of the existing methods change the value of its internal fields (at best, you’ll get a new instance returned). In other words, DateTime is an immutable type: after creating one instance, you can’t really change its state!

Now, if you look at our Point type, you’ll notice that it reuses the base’s Equals and GetHashCode implementation. Yes, I’ve said we should always override those methods, but they should work fine for the purpose of this demo (though probably a bit slower than if we introduced our own overrides of these methods). So. let’s start simple:

Nothing too fancy here…we’re creating a new instance of a Point and using it as the key of a Dictionary instance. Till now, everything works out perfectly! Now, suppose we do this:

I guess that by now you’re seeing it, right? If you’re not hearing alarm bells all over the place, then you should probably make a pause and read the info on the Dictionary class. Specifically, the part where it says this:

Retrieving a value by using its key is very fast, close to O(1), because the Dictionary<TKey, TValue> class is implemented as a hash table.

oopss…if you’ve run the previous code, you’ll notice that a.GetHashCode no longer returns the same value you got in the previous snippet. In fact, go ahead and try to get the previous entry from the hashtable variable:

And here’s the result in my machine (the 1 you see is the total number of entries in the hashtable variable):

It seems like you just can’t get the existing entry from the dictionary through the Point instance variable that was used as key. Not good, right? Well, let’s see how we can improve our code to solve this kind of problem. We’ve got several options, but my favorite is turning Point into an immutable instance:

I didn’t really follow all the recommendations I’ve mentioned in the previous post (I’ll leave that to you :) ) but now we’ve solved the previous problems. Since point is immutable, you cannot change an instance after creating it and now the hash code stays constant along the instance lifetime.

Notice that I will only calculate the hash code once and only if someone asks for it. If you’re creating a new instance type, you can follow several of the principles presented in this sample. For instance, you should always strive to define which fields are immutable (if you don’t have one, then you can always add one!) and rely on them for calculating the hash code. Since this has become a rather large post, I wont be boring you with an example that shows how this can be done. Instead, I’ll simply redirect you to take a look at the S#arp project, which has some interesting base classes you can reuse to solve these problems.

And that’s it. Stay tuned for more.

Yep, it’s true: I’m still alive! After a long pause on blogging (due to a future project which I’ll talk about in a future post), I’m back…And with a very interesting topic. Comparison between objects is something which developers tend to do a lot. By default, all objects inherit the Object’s Equals virtual method, which returns true if both objects refer to the exactly the same object. According to  the excellent CLR via C#, here’s how that code might look like (I say might look because equality is implemented as an extern method):

In other words, you’re running an identity check. This approach might not be enough for you. In fact, many people say that the base Equals method implementation should look like this:

There’s a lot going on here. We start by checking against null (obviously, if obj is null, we can simply return false). We then proceed and compare the object’s types. If they don’t match, then false it is. Finally, we need to check the fields values of both objects. Since Object doesn’t have any fields, then we can return true. Now, there are two conclusions you can take from the previous snippet:

• the first, is that you shouldn’t really use Equals to perform identity checks because Equals is virtual and that means that a derived class might change the way that method works. If you want to perform an identity check, then you should use the static ReferenceEquals method (defined by the  Object type).
• the second is that having a poor Equal’s implementation means that the rules for overriding it are not as simple as they should be. So, if a type overrides the Equals method, it should only call the base class’ method if the base class isn’t Object.

To make things more complex, we should also take the ValueType class into consideration. Interestingly, it overrides the Equals method and uses a similar algorithm to the last one we showed. Since it has to ensure the equality checks for its fields, it needs to resort to reflection. In practice, this means that you should provide your own implementation of the Equals methods when you create new value types classes.

When you’re creating new type, you should always ensure that it follows four rules:

• Equals must be reflexive: x.Equals(x) must always return true.
• Equals must be symmetric: x.Equals(y) should return the same result as y.Equals(x).
• Equals must be transitive: x.Equals(y) == true && y.Equals(z) == true =>x.Equals(z) == true.
• Equals must be consistent: calling the method several times with the same values should return the same results.

Now, these are the basic guarantees you need to give. There are a couple of extras things you can do too. For instance, you could make your type implement the IEquatable<T> interface to perform equals comparisons in a type safe manner. You *should* also overload the == and != operators. Their internal implementations should always reference the Equals override you’ve written.

Finally, if your object will be used in comparison operations, then you should go ahead and implement the IComparable<T> interface and overload the <, <=, > and >= operators (once again, the operators’ implementation should reuse the IComparable<T>’s CompareTo method). Hashcodes are also influenced by custom Equals method implementation, but we’ll live that discussion for a future post. Stay tuned for more.

It seems like MS renewed my ASP.NET MVP status for another year. Thanks MS!

In this last year, I’ve been working with Silverlight in several projects at work. At the same time, I’ve been writing about it and I’m proud to announce that my Silverlight book is out. Once again, if you’re living in Brazil, you should be able to get it from the local bookstores or from the distributor (Zamboni – more detais on the contact here).

Now, I guess it’s time to go back to the HTML world…

After a small JavaScript detour, I’m back into .NET land. We’ve already seen several interesting details regarding methods, but we still haven’t really discussed the concept of overloading. So, what’s method overloading? The concept is simple, but before, we should probably find a good enough definition for a method. For now, lets define a method as a name that represents a piece of code which performs some operation on a type or on an instance of a type.

If you’ve been doing C# for some type, then you know that you can have several methods with the same name, provided they have a different set of arguments. Ok, here’s a small sample which shows the concept:

The previous snippet shows how you can overload static and instance methods. In C#, you can only overload based on a different set of parameters. That means you cannot add the following method to the Student type without getting a compilation error:

Now, do keep in mind that the CLR does allow this kind of stuff, ie, it does allow you to overload with a different return type. Anyway, we’re writing C# code, so to achieve that, we really need to write IL (which is not going to happen right now, so we’ll consider this paragraph a small side note:)).

Ok, back to C#…so why doesn’t C# allow overloads based in the return type? That happens because overloading is based on having different method signatures. In C#, a method signature consists of its name, the number of type parameters and the type and kind of each of its parameters (considered from left to right). Besides the return type, in C# the params keyword and the type parameter constraint (when you’re using generics) aren’t part of the method signature. Another interesting gotcha is that you cannot override solely based in the out/ref modifiers (as we’ve seen that in the past). Interestingly, the our/ref keywords are considered part of the signature for hiding/overriding purposes.

Overload resolution is an important concept which is used to decide which method will be called when you' write code like the following:

The algorithm for finding a method involves several steps. Instead of describing the complete process here (which would involve some serious copying of the C# spec) and since  this is becoming a large post, I guess I’ll just redirect you to the C# spec for getting the complete story on method overload resolution. So, open your C# spec and read the 7.5.5.1 section carefully to see what I mean…And that’s it for now. Tomorrow, we’ll continue our basic tour around .NET and the CLR. Stay tuned for more.

Even though I’ve been in Silverlight/C#/WCF land in these last months, the truth is that I’ve always been a JavaScript aficionado. In fact, if you’ve been reading my blog, you’ll probably recall a small series I’ve done on it a few months ago(if not, then don’t worry: you can still read it here). After speaking with a friend today, I think I might have missed a cool advice on how to define constructors in JavaScript.

As we all know, JavaScript OO programming is a little different from what we’re used to in traditional languages like C# or Java. You see, you can’t really reuse the same style of programming because things work in a completely different way in JavaScript land. Anyway, I still believe that it’s one of the coolest, more flexible languages you can use  (provided you don’t try to write JavaScript a la C# or Java). I’m not really getting into details here, but there are times where you want to create a constructor. oh, and yes, in JavaScript a function can be a constructor. And this is where problems might occur. Let’s start with a simple example:

Ok, so can you see what’s happening here? Btw, before you start laughing, I’ve seen this happen  in the past (yes, in the real world!). When Point was created, it was meant to be used as constructor. But that doesn’t mean that a rookie or someone who is not paying attention can’t  call the Point function directly without using the new instruction. When that happens, the this special variable won’t point to a Point instance. In this case, it was probably referencing the window object, but it all depends on the existing context at time of invocation.

Now, if you’re writing frameworks, this is really a nightmare. You need to have some way of not allowing this. The good news is that there’s a way to fix this and it involves using the instanceof operator in 2 or 3 lines of code. Take a look at the next snippet:

And that’s it! really! When the function is invoked, we start by checking if this points to an instance of Point. When you use new, this does reference a Point instance. However, that doesn’t happen when you call the Point function as a function. With this small change, you’re ensuring that you’ll always get a new initialized Point instance from that method. Wasn’t that easy enough? And that’s it for now. Stay tuned for more.

In some languages (ex.: C#), you can customize the way an operator works. For instance, if you take a look at the String type, you’ll notice that it has these peculiar looking methods:

What you’re seeing here is known as operator overloading. Since the String class introduced these methods, you can write the following code to compare strings (btw, when comparing strings, you probably should be more explicit so that someone  that reads your code in the future knows exactly which type of comparison you’re performing):

Operator overloading isn’t a CLR feature, but a compiler feature. In other words, the compiler is responsible for mapping the operators used in the source code into a method call which can be understood by the CLR. Now, in theory, you’re probably thinking that you can call the static method shown before directly:

But no, the truth is that you can’t do that (if you try, you’ll get a compiler error which says something like “invalid term: operator”). Even though the CLR doesn’t understand operators, it does specify how languages should expose operator overloads. If a language decides to support operator overload, then it must follow the CLR defined syntax and it must generate methods which match the expected signature. In the case of the == operator, the compiler is supposed to generate an op_Equality method. In case you’re thinking of trying to call that method directly from C#, don’t: you’ll end up getting a compilation error saying that you cannot access the op_Equality method directly.

Before we proceed, you should probably take a look at the complete method name list from here. If you’ve checked it, then you’ve probably noticed that the table has an extra column, called Name or alternative method. When I said that the C# compiler generated a special method for the operator overload, I didn’t mention one important detail: besides respecting the name defined by the CLR, it will also set a flag in the metadata of the method saying that this is a special method which can be used “as an operator”.

When you’re writing code from  a language which doesn’t support operator overloading, you can still introduce the op_XXX methods. Now, the problem is that you also need to have the special flag applied to that method. If you don’t have it, then you won’t be able to use the operator when consuming the type from, say C#. And that’s one of the reasons why you have the friendly name column in that table. MS recommends that you add those methods when you overload operators so that you can always perform the intended operation (as you might expect, these methods will always redirect to the adequate op_XXX methods). I believe MS could have done better here, but  we have to live with what we have, right? And I guess that’s it for now. Stay tuned for more.