Eric Gunnerson's C# Compendium

Security is another I've heard mentioned.

I guess I immediately think of the MTS/COM+ stuff: automatic transaction control, object pooling, JITA, ...

I could be a bit confused, and indeed 'logging' may refer to my requirements, but I'd like to be able to treat methods and properties as first class objects (as in the prior post comment) for firing events, instead of continued code duplication.

Look under the user samples on GotDotNet under "Automatic Exception Handling".

http://www.gotdotnet.com/Community/UserSamples/Details.aspx?SampleGuid=44d0b1c7-4a9f-463b-bbac-952ea32b1a96

All the AOP scenarios are easy to find - just speak to the SQL Server team and find out the scenarios people use Triggers for. In my mind, AOP and Triggers are very similar technologies - they are actions that occur out of sequence with the normal flow.

I find Triggers abhorent.

In your MagicMethodContext, you could combine it with new StackTrace().GetFrame(1).GetMethod() to get the method of the caller. This way you can have a global definition of routines independent of any class-specific methods.

Damn logging. It is a flogged horse.

AOP is all about "modularizing cross-cutting concerns". There are many of these:

Logging & tracing
Testing (e.g. Virtual Mock Objects)
Transactions
Persistence
Session management
Error handling
Controller logic
Controller invariants
Security
Temporal Logic
Notification
Enforcing Policy
...

In general, it is hard to go back to coding without AOP in some scenarios.

E.g. you have a web action that needs to do some kind of work.

Usual Code:

deal with sessions
handle exceptions for when to commit/rollback
handle invarients
etc

AOP Modularized:

just the business logic

the DRY principle tells us that AOP can be of use.

To make AOP *really* cool, the CLR should evolve like the JRockit JVM is. At the moment we find ourselves mucking around with factories all the time. This is a code smell that tells us that the language isn't allowing us to do something. Imagine if a VM would allow you to register interceptors so when you did foo.doBar(), foo wouldn't be a pointer that just goes and calls a method, but is a proxy itself. This would be useful for all middleware concerns.

To get around this we use bytecode manipulation (or proxies, for a poorer mans), but we don't have to!

Dion Almaer

For me, when I think AOP - I think three things:

1) instrumentation. AOP would be nice for this, although I use log4net and am quite happy littering log statements around - all I really want here is to be able to get the values of parameters in a stack trace!

2) patterns. Singleton, monospace, factory, state, strategy - how many times have we all implemented these? AOP will give these and more..

3) extension - the MAIN reason I'd like AOP would be to be able to put all those changes into the language that I've always wanted. I could simulate const, I could simulate non-null, I can add methods to existing classes, in fact to every class in the system.

However - thinking about it, while really tricky programming in aspects could give me most of what I want... What I'm really trying to achieve, and what I would much prefer is just some sort of preprocessor functionality - or more specifically something that allows me to put embed c# code in my c# code which modifies the codedom as it's compiling - basically so I can say things like "whenever a parameter is declared, if it doesn't have nullable<>" around the type, put "nonull<>" around the type.

it's funny - even though we all agreed on how bad #define was... we all used it, didn't we? :) It's the whole domain-specific language thing.

There's a great book ("Generative Programming" Czarnecki/Eisenecker) that talks about code generation and intentional languages that has a lot of points I really admire...

We have our general purpose language (c#), but we always want to build a language on top of it, which is our "rock-solid-business entity language" - or "bloody fast game language" language, and write our _actual_ code on top of that language. Code generators (like the forms designer, dataset designer or the brilliant CodeSmith) are great, but they have the following serious problems:
1) they produce visible code
this is a BAD thing... I always thought the great thing VB had over delphi was that when you designed a form, you didn't get to see all the plumbing they put in - I was horrified to see VS.Net show you all that stuff... and joyous to see 2005 and partial classes trying to hide it from us again. Code Generation is only truly great when no one can touch the underlying code. Then it becomes a live thing, instead of either a once off, or a complex reverse engineering effort + high visible complexity.

2) IDE sacrifice
The thing is, the dataset designer and codesmith can be set to produce mostly invisible code, which is great... most of the time you ignore the behind the scenes c# file, and life is groovy.
Trouble is, if I write code in codesmith, (which I do a lot) I completely sacrifice all the IDE help that makes VS great - suddenly I'm just in the codesmith editor - no intellisense, crap syntax highlighting etc.

3) Large granularity
As well, when you use some sort of code generator, you separate yourself from C#. You have to do a whole class (although partial classes gets us away from this a bit).. at once. Even with partial classes, you have to do whole methods.. There's no way to say "whenever I put in the word DeclareSerializationContructor - generate this code" - or even better, "anything that implements ISerializable, generate this code"

4) Context
Finally, because the generation isn't part of the compilation process, the code can't take into account context. For instance, I'd like to do things like say "any caller of this function should also generate code to provide me details of the parameters they are sending me, such as their names"

So - what it comes down to is that aspects are nice, and step us a bit of the way there, but I'd much prefer a decent code generation facility which was understood by the IDE (maybe placed markers where code would be generated, and followed intellisense through the code generation - so if the generator would produce four new methods on a class, those four methods appear in intellisense) and ran during compilation. From this, I could do literally ANYTHING I wanted, build levels of increasingly domain specific languages on top of C#, and not sacrifice _any_ performance, as highly specific code is being generated when I compile, and not sacrifice _any_ robustness, as I can generate all sorts of strongly typed validations and checks.

PingBack from http://uniformstores.info/story.php?id=42476