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?

One of the only thoughts I captured this Tuesday (at least in the subset of thoughts implementable using PostSharp): a graphical language to express matching patterns in source.

Second day at ECOOP 2007 and still the unpleasant feeling I am a dumb. Oh my god, where are the times, six years ago when I finished university, where I was as brilliant as them? Is this collapse the result of six years in industry? Or just of the last months spent in drawing TIBCO business processes?

Anyway, I understood enough to catch a good idea: a graphical way to express "matching rules". Matching rules are expressions that identify points in code where aspects should be applied. In the AspectJ world, one say that matching rules are pointcuts and matched points are join points. While designing PostSharp Laos, I have chosen not to refer to these concepts and I am happy to see that Microsoft did actually the same. There are actually matching rules in PostSharp Laos, but you do not see them. They are hidden behind the "attribute multicasting" mechanism: actually, when you define a filter on a multicast attribute, you define a matching rule.

Of course, the expressiveness of matching rules of multicast attributes is limited. Microsoft Enterprise Library has a richer model for that, even if its usability is questionable.

The idea is to use the same graphical language to express matching rules (or patterns) than to express the model. That means that we could use a similar language than UML. Suppose we want to match all classes having a method Dispose(). We would draw a class and add a Dispose() method to this. And if we want to restrict the classes to belong to a given namespace, we would for instance specify the name of the class with wildcards. That is, what we specify in UML elements become constraints. What we don't specify are free variables that do not play any role in the pattern matching mechanism.

Some thoughts about my first day at the European Conference on Object-Oriented Programming: how to cope with conflicts when different aspects apply to the same method?

Yesterday was my first day in Berlin at ECOOP 2007. I have attempted the 2nd International Workshop on Aspects, Dependencies and Interactions which studies, as its name indicates, what happens when you put many aspects together. Will there be a conflict? Or, contrarily, does one aspect depend of another?

My first impression was how far I've come from the academic world during these 6 years since I've left university. Academic and developers' communities differ radically by their way of thinking and their way of communication. I'm happy to have chosen my way three years ago, when I started to develop PostSharp: deliberately refuse to look at AspectJ and design a tool as a developer would design it and use it, and not according to the framework of thoughts of the academic community. It indeed was impressing to realize how AspectJ has become the horizon of AOP research, how all problems are stated in terms of AspectJ. However, the way how AspectJ is designed causes problems in itself and it is not always easy, in the academic sphere, to realize that these problems are caused by AspectJ design and might be stated in a different and more fruitful way if only they were abstracted from AspectJ.

And another thought: it's incredible how Microsoft has lost attention from researchers, at least in the AO academic community, and maybe even more generally in the OO academic community. What I'll be trying to say during my speech on Thursday is "now, thanks to PostSharp, you can use the Microsoft .NET Platform for your research work". I guess Microsoft should have sponsored me to participate in this conference and in this evangelization campaign.

It was however very interesting to me to attend this workshop, because it made me face problem that have already emerged in the AOP community, but not yet in the PostSharp one. So let's go back to these problems:

How to make sure that aspects are not applied in a conflicting way, or in a way that damages semantics of the base code?

Let's take an example: suppose I have an operation GetCustomerInfo, returning private information about customers. We want to apply two non-functional requirements to this operation: we want to cache the method and ensure that only authorized employees access this information. So we apply two aspects: caching and authorization.

The normal behavior of the aspected operation is the following:

Check the current user is authorized to retrieve the requested the piece of information. If not, throw an exception.

If the requested piece of information is in cache, return it immediately without continuing the chain of behaviors.

Retrieve the piece of information.

Store it in cache.

So now, what would happen if the cache aspect was applied before the authorization check? Well, you would have bad surprises. If the requested piece information is present in cache, authorization is simply not performed.

We can state this concrete problem: "caching cannot occur before authorization". And more abstractly: "there cannot be an aspect that interrupts the normal control flow before an authorization aspect".

Here is how the constraint could be expressed:

[AspectConstraint( ConstraintType.Forbid, AspectPosition.Before, AspectBehaviors.ChangeControlFlow )]

public class AuthorizationAspect : OnMethodBoundaryAspect



The effect of the AspectConstraint custom attribute would be that the weaver should emit code that throws a runtime exception if an aspect tries to change the normal control flow. Ideally, this kind of situation should be discovered at compile-time, but it would require PostSharp to make a static analysis of the aspect implementation to discover if the aspect tries to modify the control flow. It is theoretically possible (and fully described in academic literature), but practically much more demanding than the runtime check.

A similar interesting feature would be to allow these constraints to be applied on methods also. Suppose I have a method that performs authorization imperatively (not using an aspect). I could also want to forbid the method to be transformed by aspects that could bypass it. So it should be possible to apply this custom attribute on method as well.

Needs for dependencies check are of course much larger than this. For instance, there could be a known incompatibility between two aspects. The architect of a development team could write an XML file containing all known incompatibilities, and it would result in compile-time errors if developers try to apply aspects in an incompatible way. This is relatively easy to implement and could be useful in a probable (near?) future when PostSharp will be used in large projects...