The old design was to pass a lot of parameter to each method like OnEntry or OnExit, for instance. Each piece of context (object instance, array of arguments, arrays of generic arguments, ...) was passed as a standalone parameter.
This kind of design had serious drawbacks. The main is flexibility, i.e. forward compatibility. If I want to add a new information to the context, I have to add a new parameter... and break the public interface.
Conversely, the new design often passes a single parameter, an object containing all information about the context. This makes Laos much event oriented. A join point is like an 'event' in the code and an advice is like an 'event handler'. For instance, the OnEntry method now looks like this:
public override void OnEntry(MethodExecutionEventArgs eventArgs)
It is really similar to event handlers written in the derived class, according to the design pattern recommended by Microsoft.
I came to this idea when talking when Olaf. Aspect-oriented programming can really be seen as common event-oriented programming. It is 'just' another way to define 'events' in the code and to define event handlers. PostSharp Laos currently forces you to add the 'event handlers' at compile time, but one easily imagine extending it so that 'event handlers' can be added at runtime. What does that mean? That we get something very close to 'dynamic weaving'. But with a big difference: while event handlers can effectively be added at runtime, the events in themselves (i.e. the join points) have to be defined at compile time or at load time.
That's for another time, but the current design of PostSharp Laos makes it very easy.
Enjoy... and forgive the change in the public interface :-)
Gael