> aka Python-style decorators and context managers

Genuinely curious: aren't Python decorators basically the same as C# annotations, and aren't context managers covering the same ground as a C# using statement?

Based on my experience with C# annotations they require cooperation of the function being annotated or the code that calls it. There has to be code somewhere that checks if an annotation of expected type is present, reads its attributes and possibly executes it, and then proceeds based on results.

Python decorators are basically true proxies. The code being decorated or the code that calls it - does not need to be aware in any way of the decorator’s presence, and the decorator gets inserted into the call stack and has access to all call parameters, including the lambda of the decorated function.

Regarding context managers I would need to come back to this post, as I don’t think IDisposable is capable of solving the same use cases, but it’s not on top of my mind as to why.

> Regarding context managers I would need to come back to this post, as I don’t think IDisposable is capable of solving the same use cases, but it’s not on top of my mind as to why.

I'm definitely not as fluent in python as I am in c#, but don't context managers just allow you to define an __enter__ and __exit__ methods that are called when a `with` block begins and ends, respectively? That closely aligns to defining a constructor and .close() method on an IDisposable class, then creating an instance with a `using` statement.

According to the interviews Anders has given that has been by explicit design.

Anders very much creates 'pragmatic industry languages' that optimize for the broader use rather than the individual use. An important part of this is ability for various developers to work on each other's code bases, relatively efficiently.

The contrast to this is a Clojure where you can end up creating basically a DSL that's optimized to the problem space, but that language is then unique to the application and with a higher learning curve when a new developer has to pick it up.

In one of his interviews Anders specifically said he doesn't like AOP because it allows the creation of 'magic' that is hard to understand for other developers. And that's very true at the margins - sure the standard use cases of e.g. logging are not so hard to grok, but it's possibly to weave together incredibly complex/hard to understand/hard to reverse engineer/easy to misunderstand systems when AOP is used heavily or exotically.

So it makes perfect sense when considering he is optimising for an 'industry language' not a 'superstar whose code is hard to average developers to work with' language, that AOP is not in the core language, especially considering extensions such as PostSharp are available.

I’ve heard the same thing mentioned before, but I wonder if the same principles are still held firm or if it’s a new day. I think in the last 20 years C# has accumulated quite a bit of complexity that makes me doubt that the language designers are still firm on this. Take Roslin for an example.

I think that some concerns about possible complexity brought on by AOP are true, but I think they are pretty comparable to what one might be concerned about as it relates to Roslin.

But I am not trying to convince anyone really, I am just answering the posters question: what do I wish was added to C#.

For anyone not familiar, Roslyn is the language server for compilation, analysis and refactoring of code.

I don't understand the premise of your post but I would like to.

How does having these advanced features at the code compilation stage which is used by compiler and visual studio plugin programmers, have any affect on the complexity of application developers? The application developer doesn't have to think about Roslyn/language server at all, they just consume it's features. The application developer is concerned with the complexity/magic in the code, not how the code was compiled?

Perhaps I am not referring to the correct technology/feature if you find it so confusing? In my post all I was trying to say is that enabling writing code that generates predicates, expressions etc, literally syntactical building blocks of more code - via code in an inception-like manner - seems to be at least equally complex an endeavor as somewhat arguably non-trivial matter of creating or using python-like AOP decorator “proxies”. So presence of Roslyn kind of disproves that the emphasis on simplicity is still in effect, at least in my mind. Hope that clears up my point.

I've just happened to stumble on this discussion on a C# 11 feature, where someone who I think is on the language team (HaloFour)says ".. using source generators for AOP has been effectively rejected by the language team ..".

https://github.com/dotnet/csharplang/discussions/5735#discus...

I don’t think this is a new revelation, but rather someone re-stating what was already stated in the original doc introducing source generators that I’ve read a few month ago, around November 2021-ish? … which said something along the lines that they explicitly making it impossible to use it for AOP.

Personally I think that dogmatic crusade against AOP while adding a menagerie of syntax sugar hieroglyphics :? :: !! :+ … is a bit misguided, but whatever.

First question in the FAQ section:

https://devblogs.microsoft.com/dotnet/introducing-c-source-g...

You mean Java's "Annotation Oriented Programming"?

like @Transactional?

If yes, then I'd really do not want those "magic-like, tricky when it comes to debugging" features

Last time I used Java, it looked to me that AOP is supported with compile-time byte-code rewriting, which might explain why it may feel like magic and be hard to debug. .Net also has a IL-rewriting 3rd party toolkits that enable AOP, namely Postsharp - but my experience with it wasn’t great for similar reasons you stated. Maybe I did something incorrectly, but my impression of tools that generate code at compile time - is that you can’t step through the resulting code. Python on the other hand is both flexible and simple. The decorator code simply wraps the function it decorates (you get a lambda variable that will contain the function you annotate, so you do whatever it is you need to do, and then call the original function. Or not, your choice. ) and doesn’t feel complicated at all. Debugging is simple.

Try it and you might change your mind - perhaps C# designers could use a similar source of inspiration.

There is PostSharp for that https://www.postsharp.net/

I mention postsharp in my other reply, but I don’t see it as a compelling substitute - because it’s not a native feature of the language or framework, but also because its compile-time byte-code rewriting nature makes it hard to work with and debug. It fills a niche for sure, but I’d rather it be filled natively by the language itself.

Source generators might help with this.

Unfortunately the original doc introducing the feature makes an explicit point to say that the feature does not enable AOP.

First question in the FAQ section:

https://devblogs.microsoft.com/dotnet/introducing-c-source-g...

That’s a shame.

I think Kotlin's type delegation is probably a better way to handle method overrides/wrapping. Fits into the language better.