Subscribe
Subscribe to our newsletter for release news and a monthly status report.
You can unsubscribe at any time.
Second Day at ECOOP 2007
by Gael Fraiteur on 04 Aug 2007
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.
by Gael Fraiteur on 04 Aug 2007
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.