I know, people love aspects but they need to convince their chief architect to go this way. This white paper from Columbia University was jointly written by a panel of scientists and industry practitioners. They present two cases studies (Philips, Deutsche Post) and argue hat Microsoft should introduce support for AOP-related practices, whose a subset is already supported by PostSharp.

You can download the white paper from there:

http://mice.cs.columbia.edu/getTechreport.php?techreportID=438

by Marc Eaddy (Columbia University), Alan Cyment (University of Buenos Aires), Pierre van de Laar (Philips), Fabian Schmied (Vienna University of Technology) and Wolfgang Schult (Deutsche Post World Net)

The PostSharp Day: first public demonstration of
PostSharp.

The PostSharp Day

This forth day was for me principally the one of the demonstration of
PostSharp. The first real public demonstration. A baptism, to some extend.
The strange thing is that PostSharp was first presented to scientists and not
to developers while PostSharp was actually developed for developers and not
for scientists, and even if I am convinced that it is interesting for
scientists, there was a perceptible shift between the talk and its audience.
Let me repeat the reasons why PostSharp Core and PostSharp Laos are
interesting for researchers:

1. PostSharp Core is an infrastructure on which assembly transformation
applications, like code weavers, can be realized very easily. This kind of
platform, with that level of integration, did not exist before for the .NET
Framework. Yeah, I did not know that researchers nearly only target Java!

2. PostSharp Laos is an original and pragmatic aspect weaver. Pragmatic because
it speaks the same language as the programmer and was designed to have a flat
learning curve. Original because some features, like compile-time behaviors of
aspects, are really unique.

Componentizing Classes

The other talks I remembered from this day are all about different strategies
to componentize classes. I have already written about it in yesterday's post
with an approach named traits. So more approaches were presented, but, again,
they require language extensions or at least a pre-compilation step. It does
not means that it is uninteresting, of course (and this could be implemented
by Visual Studio generating partial classes), but it cannot be implemented
using PostSharp.

There is a Czech proverb telling that when you have a hammer, everything looks
like a nail, but here there is even no resemblance…

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

{

[EqualityKey]

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…

Traits

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?