[aosd-discuss] Is there a standard .Net Aspect software package?

[Rolf Huisman]

> In the .NET world there is not one single language , there are C#, VB.NET
, managed C++ and a gazillion other homegrown languages.

> So making a specific language for AOP in .NET is (in my oppinion) the
wrong way to go, since it would only be useful for a fraction of the .NET
community, eg only C# developers.

> It also requires quite a bit of work, developing an entire IDE, compiler
and everything else that comes with it..

 

> Code mangling is powerful and could be applied to pretty much any .net
assembly , compiled from any language.

> Sadly code mangling comes with a few drawbacks, eg very hard to make a
debugger for it, and without any debugger it will fall dead to the ground.

 

Yes, it would be stupid to recreate visual studio

You need to extend visual studio or any other IDE the programmers use so you
don't have to do the work the programmers already did.

 

Yes, code mangling is powerful and in combination with the IL pretty
programming language independent.

You therefore need a language independent specification language 

 

However code mangling and debugging don't bite if you do it correctly.

The main problem for debugging mangled code is maintaining the references. 

If you don't, you just don't know how to properly build an IL weaver.

http://wwwhome.cs.utwente.nl/~huismanrlr/afstuderen/Microsoft%20Debugger.doc

However if you preserve the code reference in your .net assembly you still
build a debugger or sometimes even use the standard .NET one..

 

And guess what, that's what WE did in .NET our AOP Compose*
http://composestar.sf.net <http://composestar.sf.net/> .

And since the specification language is language independent the C and Java
version are just around the horizon.

 

With regards,

 

Ing. Rolf Huisman

Master Student University of Twente

 

  _____  

Van: discuss-bounces at aosd.net [mailto:discuss-bounces at aosd.net] Namens Roger
Johansson
Verzonden: donderdag 15 juni 2006 18:04
Aan: discuss at aosd.net
Onderwerp: Re: [aosd-discuss] Is there a standard .Net Aspect software
package?

 

If anyone want to try out NAspect but gets stuck due to sparse documentation
please let me know :-)

Im currently working on the documentation and going to add more samples as
soon as I get my thumb out..

(www.puzzleframework.com)

 

Regarding the lack of some standard approach for .NET:

 

I think this is quite different from how things are in the java world.

In the java world there is just java.

So when the AspectJ guys came along they could simply take java and create
AspectJ.

And it could be used by any Java developer.

 

In the .NET world there is not one single language , there are C#, VB.NET ,
managed C++ and a gazillion other homegrown languages.

So making a specific language for AOP in .NET is (in my oppinion) the wrong
way to go, since it would only be useful for a fraction of the .NET
community, eg only C# developers.

It also requires quite a bit of work, developing an entire IDE, compiler and
everything else that comes with it..

 

So (I think) the solution have to work with any language, then we have a few
other approaches , code mangling and dynamic proxies.

 

Code mangling is powerful and could be applied to pretty much any .net
assembly , compiled from any language.

Sadly code mangling comes with a few drawbacks, eg very hard to make a
debugger for it, and without any debugger it will fall dead to the ground.

 

Dynamic proxies is less powerful than code mangling , but proxied code is
very easy to debug, which is good.. 

But proxies come with some other drawbacks,  you have to create your
instances via factories and you can only apply aspects to non sealed classes
with virtual methods via interface proxies which also  comes with some
severe identity problems.

 

So I can't say that any of the approaches are very good for .NET.

I used dynamic proxies in NAspect simply because it was enough for my own
needs and Im not too keen on breaking OO rules, so inheritance based AOP was
fine for me.. 

but Im well aware that it doesnt cover the needs of everyone else..

 

I think we might never get a common system for AOP unless MS decides to
support interception and mixins (not extension methods) in the framework
itself.

 

Untill then, I guess we have to pick the approach that fits our specific use
cases the best..

 

//Roger

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/discuss_aosd.net/attachments/20060615/c9e78b1c/attachment-0001.html