Third Day at ECOOP 2007

by Gael Fraiteur on 04 Aug 2007

Object Equality, Traits and Non-Nulls.

The previous two days were full-days workshops on the same topic. Now the main conference has really started, there are a lot more of small topics and a lot more of ideas to pick. Here are some.

Declarative Object Identity

The idea presented there is that much effort is spent to develop non-default implementations of the GetHashCode and Equals methods, and empirical studies of these implementations show that this code is either boiler plate code either buggy. So the proposal was to implement these methods automatically so that equality is tested based on the values of 'key' fields in the object. Key fields may be decorated with an [EqualityKey] custom attribute, for instance:

public class Customer



int customerId;

string firstName, lastName;


Good idea, and easy to implement in PostSharp using the low-level API.

The problem is that in C# it would not be possible to write so simply "customerA == customerB" to have this equality working. Why? Because, the C# compiler does not generate a call to the Equals method but simply compares both pointers. You need to override the == operator. And here it does not help to implement it at post-compile time, because it needs to be present at compile-time in order for the compiler to use it. Another solution would be to replace the "equals" instruction by a call to the Equals method at compile-time, but it is not possible (or too difficult) with the current version of PostSharp, and anyway it is not nice at all.

So we are maybe in front of a problem that is best solved by a code generation technique, before compilation...


A trait is a component that can be inserted into a class. So a class can be assembled from traits and have its own artifacts. No, it does not exists in C#. But say we would have a good support for traits; our problem above with equality checking would find an easy solution. Again, not something for PostSharp.

Non-Null Annotations

It's not common in C# but more and more frequent in Java: you can annotate fields and parameters with a [NonNull] custom attribute. and you get compile-time and runtime errors when you try to assign a null value to such a field or parameter.

The problem is: empirical studies that more than 75% of fields or parameters are meant to be non-null by design. This suggest that the default behavior should be to be non-null...

By the way, who starts writing a static analysis library for .NET and integrate it into PostSharp?