4 ms·

I wish for just one thing: native AOP (aspect oriented programming) aka Python-style decorators and context managers. Everything else I need C# already covers a

I wish for just one thing: native AOP (aspect oriented programming) aka Python-style decorators and context managers. Everything else I need C# already covers adequately.

tester756 5y ago
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
- VincentEvans 5y ago
  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.
giaour 5y ago
> 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?
- VincentEvans 5y ago
  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.
  - giaour 5y ago
    > 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.
jayd16 5y ago
I think Kotlin's type delegation is probably a better way to handle method overrides/wrapping. Fits into the language better.
yread 5y ago
There is PostSharp for that https://www.postsharp.net/ https://www.postsharp.net/
- VincentEvans 5y ago
  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.
  - Izikiel43 5y ago
    Source generators might help with this.
    - VincentEvans 5y ago
      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-generators/ https://devblogs.microsoft.com/dotnet/introducing-c-source-g...
      - Izikiel43 5y ago
        That’s a shame.
hackerfromthefu 5y ago
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.
- VincentEvans 5y ago
  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#.
  - hackerfromthefu 5y ago
    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?

I wish for just one thing: native AOP (aspect oriented programming) aka Python-style decorators and context managers. Everything else I need C# already covers adequately.

tester756 5y ago

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

VincentEvans 5y ago
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.

giaour 5y ago

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

VincentEvans 5y ago
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.
- giaour 5y ago
  > 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.

jayd16 5y ago

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

yread 5y ago

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

VincentEvans 5y ago
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.
- Izikiel43 5y ago
  Source generators might help with this.
  - VincentEvans 5y ago
    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-generators/ https://devblogs.microsoft.com/dotnet/introducing-c-source-g...
    - Izikiel43 5y ago
      That’s a shame.

hackerfromthefu 5y ago

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.

VincentEvans 5y ago
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#.
- hackerfromthefu 5y ago
  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?