views:

131

answers:

3

I've had some interesting debates with colleagues about the merits if incorporating aspect oriented programming as a native paradigm to the C# language.

The debate seems to be divided into three camps:

  1. Those folks who think that C# is already too complicated as it is, and another major feature like AOP would only muddy the waters further.
  2. Those who think that it would be a great addition because anything that can increase the expressiveness of the language without breaking existing is a good thing.
  3. Those who don't think it's necessary because libraries like PostSharp that perform post-compilation IL weaving already allow it in a language neutral way.

I'm curious what the community of C#/.NET developers out there think.

+2  A: 

I agree with the first camp. C# is already loaded with features. Leverage the PostSharp library instead.

Chuck Conway
In my experience, PostSharp was so limited in what it allowed I didn't see the point in using it, but then I am spoiled with using AspectJ.
James Black
Some questions: 1) How would integrating AoP into the language (rather than using a library like PS) harm C#? Wouldn't developers who don't want to use it ignore it, those who do would have as much to learn in using PS as in a language feature. 2) Wouldn't an implementation that is integrated into the platform (CLR) or language (C#) be less likely to break or introduce problems than a library that's tacked on after the fact?
LBushkin
@LBushkin: One could argue the exact opposite way as well: Any additional feature being added to the language introduces a new higher level of complexity in the compilers, runtime and/or framework toolset - making it even more difficult to keep everything tidy, stable, maintainable, fast and easily optimizable.
0xA3
...and, the most important point why adding a new feature to language should be considered with care: "Once you add a feature, it's in the language forever." (Eric Gunnerson, http://blogs.msdn.com/ericgu/archive/2004/01/12/57985.aspx)
0xA3
@LBushkin - The problem with adding AOP to the language is that you have to then have tools to allow people to see what is going on, which is a lot of work for what a relatively small number of people will take into production.
James Black
A: 

It would be useful, but many of the uses are being included in various ways as it is. For example, we will have the ability to do post and pre validation in .NET4, which was one use for using around, in aspectJ.

By using extension methods you can inject new methods into objects you may not have source code for.

And, I don't believe it would be used much as C# developers seem to approach problems differently than Java programmers, which is easy to do since the two languages have diverged so much now.

I don't know if the companies that tend to use .NET would want to use something like AOP, and you would need tools to help understand what aspects are being injected where, such as AJDT on Eclipse.

James Black
PostSharp 2.0 now has something like AJDT for Visual Studio.
Gael Fraiteur
@Gael Fraiteur - Thank you for the info. The only way I can really do AOP in Java is AJDT, otherwise I have no idea what is really happening. Glad that PostSharp 2 has something like that. I found myself getting frustrated with the fact that it isn't as flexible as AspectJ so I have found other ways to do what I am trying, such as the extension methods.
James Black
And PostSharp 2.0 has advices and even disguised pointcuts (although support for pointcuts were quite limited in CTP1) :).
Gael Fraiteur
I will have to look at PostSharp 2.0, I may find it more useful than when I experimented with PostSharp 1
James Black
+1  A: 

It would be great if languages would make it easier to develop and use AOP extensions.

For instance:

  • It would be nice if one could give a delegate (or anonymous method, or lambda) as a parameter to a custom attribute. It's not a lot of work to implement this in C#, it's quite easy to implement it in the CLR (since it supports types, why not methods?). And it would allow to express 'pointcuts' in an elegant way.

  • Support for 'fieldof' and 'methodof'. It is somewhat supported by the CLR (with bugs), not by C#. The same for 'eventof' and 'propertyof' (they have currently no support in the CLR).

  • Better debugging symbols could make it easier for an aspect weaver to report error messages and give the location in code.

  • It would be great to have a modular compiler; it would be less expensive to implement some features like source code generation based on aspects (for method and interface introductions).

That said, I don't think that the language should provide AOP extensions. This is too large (I think PostSharp 2.0 is more complex than the C# compiler itself, at least than C# 2.0). Let's face it: AOP is still rather experimental in the sense that we still don't know exactly what we want from it. There is still little experience. But we want the specification of a language to be stable and to address well-understood problems (imagine the Entity Framework were a part of the language).

Additionally, there are different ways to achieve AOP, and build-time is only one of them. There is nothing wrong in using runtime technologies, like JIT-emitted proxies (Spring/Castle); these are just for different use cases and have their own pros and cons.

So my opinion in one sentense: yes for limited and well-defined language extensions that make it easier to develop AOP frameworks; no for a full AOP implementation in the language.

Gael Fraiteur
Regarding fieldof, methodof etc, you should read this post by Eric Lippert : http://blogs.msdn.com/ericlippert/archive/2009/05/21/in-foof-we-trust-a-dialogue.aspx. BTW, I doubt Eric would agree with this statement : "It's not a lot of work to implement this in C#" ;). According to him even very simple features require a lot of work.
Thomas Levesque
I cannot agree it is major work. I can understand any minor work requires enormous effort in Microsoft and that's why we are able to develop a complex tool like PostSharp in a fraction of the cost it would take to Microsoft. And I don't agree with his argument that there is not anything that we can do with methodof and cannot do without, since the only alternative is reflection, and reflection does not resist obfuscation (not speaking of refactoring).
Gael Fraiteur