[GEEK] Language Lust

[jducoeur]

So in my spare moments today, I'm finally getting around to reading into AspectJ, the aspect-oriented extension language for Java.

Oh, this is so cool. I've been vaguely familiar with the concept of aspect-oriented programming, but never really dug into it to see what a proper implementation looks like. The semi-declarative nature of the language appeals quite a bit to me, even if I don't love some of their syntax choices. And it's easy to see how a disciplined use of this mechanism could result in a significantly better architecture in many systems. (I suspect that the scripting engine I wrote for my current job would have worked quite differently if I'd had these tools.)

I want. I think I need to give some thought to how one could apply these concepts to .NET/C#, and whether the key concepts could be layered on top of it. The metadata parts are easy, but I'm not sure there's any straightforward way to define pointcuts without hacking the compiler -- I don't recall any native .NET support for interception...

Comments

errrr

[dmnsqrl.livejournal.com]

don't suppose you know a helpful "what da heck is aspect-oriented code" reference?

Re: errrr

[jducoeur]

Read the first chapter of the AspectJ documentation. I think that does a fairly good idea of giving the high concept...

Re: errrr

[russkay.livejournal.com]

try this explanation out:

http://www.computerworld.com/developmenttopics/development/story/0,10801,85621,00.html

Re: errrr

[dmnsqrl.livejournal.com]

hey, thanks :)

Unconvinced...

[metageek.livejournal.com]

I've been reading the AspectJ introduction, and I'm unconvinced. I'm disturbed by the notion of altering a function by adding some declaration somewhere else; and I'm pretty sure that a lot of the benefits they tout can be had with multiple inheritance. For example:

Inter-type declarations in AspectJ are declarations that cut across classes and their hierarchies. They may declare members that cut across multiple classes, or change the inheritance relationship between classes. Unlike advice, which operates primarily dynamically, introduction operates statically, at compile-time.

Consider the problem of expressing a capability shared by some existing classes that are already part of a class hierarchy, i.e. they already extend a class. In Java, one creates an interface that captures this new capability, and then adds to each affected class a method that implements this interface.

But that's exactly what multiple inheritance is for. Java decided that multiple inheritance was too complicated, so now people have come up with something even more complicated to do the same job.

Re: Unconvinced...

[jducoeur]

I disagree. I mean, you're correct that many of these things *can* be done with multiple inheritance; the more interesting question is whether they *should*. I'm actually fond of multiple inheritance, especially the "mix-in" style with primary and secondary inheritances. But it isn't the ideal solution for the kinds of problems that AOP is going after.

For the most part, I think they choose their examples well in the tutorial. The point of AOP is for problems when you're really trying to define the *context* of an object, not the object itself. I was particularly intrigued to note the focus on use of AOP at development time, which makes a lot of sense to me. Consider how much AOP is like what one always does with a debugger: in a very real sense, this is a relatively complete and thought-through debugging framework.

More generally, the cases where AOP seems to make sense is when the functionality you're trying to achieve is not necessarily a consonant part of the object itself: when the functionality is all about the context of the object. Truth to tell, I do a lot of that already, using C# attributes, and that's the way I look at this -- a much more complete version of attributes. Like attributes, you can add metadata to your objects as needed. Unlike attributes, you can add meta-*functions* to your objects. That's a very neat and useful idea.

As for complicated, I disagree completely. Look at the examples they provide: in almost all cases, those examples are significantly *simpler* than what you'd have to do in any multiple-inheritance scenario I can think of. More importantly, they're far better *encapsulated* than multiple-inheritance solutions would be. I don't agree with absolutely every example (in particiular, I think that programming-by-contract is better done more explicitly), but I think many of them show excellent and sensible encapsulation.

AOP is subtle stuff, and it's not to be overused: like any programming tool, it's easily abuseable. But I think the notion of cross-cutting concerns is quite real, and their solution seems like a good one. (At least, if they can do it efficiently.) Like metadata, it's only going to be useful once in a while, but when you want it, you want it. I can think of a number of cases in my current engine that would do well with it. So I do hope that the idea makes it more into the mainstream...