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

[Roger Johansson]

As I stated in my previous post, there are pros and cons of each approach.
For example you are making some sort of extension for C# and J# ?
So every VB.NET are left out.. cutting away some 60% of the .net community.

I must admit that I know very little of your implementation, but in general static weavers can have a whole bunch of problems , eg.
making it work with asp.net. and you might have to recompile to apply changes to aspects etc.

So really dont think there will be one solution that solves it all.
Each approach is good in some scenarios and bad in others.

For example, we could never use a static weaver for NPersist , that would force the users to use that weaver themselves onto their domain classes, that would really suck when all they wanted was to map objects to a database.
So a static weaver for an ORMapper framework is really bad.

And you cannot use a dynamic proxy approach if you want to apply aspects to some 3rd party lib that returns entire object graphs because that lib will not create its objects through the dynamic proxy factory.. so that would be really bad in that case...

Just use the right tool for the job.

//Roger


  ----- Original Message ----- 
  From: Rolf Huisman 
  To: 'Roger Johansson' 
  Sent: Thursday, June 15, 2006 6:50 PM
  Subject: RE: [aosd-discuss] Is there a standard .Net Aspect software package?


  > 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.

  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

   

   

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