C# doesn't support AOP because it already supports AOP...



  • Continuing the discussion from Tell me how wrong and stupid I am about T-SQL transactions:

    @Jaime said:

    AOP is Aspect Oriented Programming. It will never be properly supported in .Net because Anders Hejlsberg has bluntly answered "No" when asked if he will ever support it.

    Wat. I thought the entire point of the attributes system was to support AOP. Attributes can be used to "inject" code into classes and functions in a manner not entirely unlike AOP, can they not?

    [SomeAttributeImplyingAnAspect(...)]
    class MyClass {
        // ...
    }
    

    Is Anders just being a troll here? Or is he using "AOP" to mean something unlike what anyone else means by "AOP"? Or does he have some hate-boner for AOP?

    (Also if anyone can pull up any more cites to where he said this that'd be nice too...)



  • @tar said:

    AOP is Aspect Oriented Programming.

    From Wiki:

    aspect-oriented programming (AOP) is a programming paradigm that aims to increase modularity by allowing the separation of cross-cutting concerns

    Maybe he simply, just like me, didn't understand a single word of that definition and decided to play it safe.



  • @Maciejasjmj said:

    Maybe he simply, just like me, didn't understand a single word of that definition and decided to play it safe.

    It's possible, but he's reputed to be a smart guy, so I would think he could wrap his head around it...


  • FoxDev

    The .NET Framework is the first in the list FFS πŸ˜†



  • @tar said:

    Attributes can be used to "inject" code into classes and functions in a manner not entirely unlike AOP, can they not?

    AOP, in its purest sense, implies that there's a means for injecting code into a programmer-definable set of methods that is syntactically invisible when the applied-to methods are examined.



  • @RaceProUK said:

    The .NET Framework is the first in the list FFS πŸ˜†

    Yeah, something is amiss here. I did find this in the cite I added to the OP. (It also has a video, but I CBA to watch it right now...)

    Anders Hejlsberg fails to acknowledge the need for better support for meta-programming in C#, which is what AOP addresses. It’s not just about me and several thousand PostSharp users. Many teams in Microsoft itself have identified the same need. Windows Communication Framework (WCF) has its AOP framework (generalized into custom behaviors). ASP.NET MVC has its own (filters). Unity and PIAB have their own. Folks from Code Contracts would probably have appreciated the ability to hook the compiler. This need is largely being ignored.



  • @tarunik said:

    AOP, in its purest sense, implies that there's a means for injecting code into a programmer-definable set of methods that is syntactically invisible when the applied-to methods are examined.

    So because attributes are added manually by the developers, they fail to make the grade?



  • @tar said:

    So because attributes are added manually by the developers, they fail to make the grade?

    From my standpoint, yes -- I'd rather have attributes/decorators/... than AOP though, because a decorator at place Y that names X says that X is taking place at place Y, whereas, in say AspectJ, the thing that says that X is taking place at place Y is off by where X is defined, not living with Y.

    Spooky action at a distance is bad.


  • Discourse touched me in a no-no place

    Glad it wasn't just me.



  • @tar said:

    So because attributes are added manually by the developers, they fail to make the grade?

    It's because attributes can't decide to execute themselves. For example, a classic AOP example is logging. You simply write this:

    [Log("Firing Ion Cannon")]
    public void FireIonCannon()
    {
    }
    

    ... and the code to perform logging does its thing when the method is called. This can't be done today in .Net with attributes.



  • @tarunik said:

    Spooky action at a distance is bad.

    In general, sure, but I think I can see some situations where it might be useful.

    Firstly, if you have an existing large codebase, and you have a potential bugfix or enhancement that needs to break the API. You could use AOP to inject your proposed changes into the codebase as-is to see if your solution is valid. If it is, then you can invest the effort in changing every call site to support the new API. If your changes aren't valid, then hey, you just saved yourself however many hours of grunt work for no benefit.

    Secondly, maybe you're stuck with a third-party library that you don't have source for, and it's just plain buggy. You can use AOP to inject bugfixes into the third-party code, and then life is just kittens and unicorns forever.



  • @tar said:

    Firstly, if you have an existing large codebase, and you have a potential bugfix or enhancement that needs to break the API. You could use AOP to inject your proposed changes into the codebase as-is to see if your solution is valid. If it is, then you can invest the effort in changing every call site to support the new API. If your changes aren't valid, then hey, you just saved yourself however many hours of grunt work for no benefit.

    Branching and test servers, my friend.

    @tar said:

    Secondly, maybe you're stuck with a third-party library that you don't have source for, and it's just plain buggy. You can use AOP to inject bugfixes into the third-party code, and then life is just kittens and unicorns forever.

    Most AOP techniques require source-level access to the code being operated on, AIUI -- I've done binary monkey-patching of closed-source code before, and it's gruesome.


  • kills Dumbledore

    This thread has made me realise I have no idea about AOP or C# attributes.



  • @Maciejasjmj said:

    Maybe he simply, just like me, didn't understand a single word of that definition and decided to play it safe.

    I understand almost all of the words of the definition. Putting them together in that sequence, however, ...



  • @Jaloopa said:

    This thread has made me realise I have no idea about AOP or C# attributes.

    I've implemented my own attributes precisely once: to provide a [DefaultValue(x)] attribute for properties of an msbuild Task that I wrote. (The system provides a few custom attributes for Task properties, but not that one...) I remember thinking that it was remarkably annoying, I had to use reflection to go digging around in something's constructor to get it to work (will check details when back at work...)

    Filed under: (X) {X} [X] <blink>(X) {X} [X]



  • I think the relatable example of where AOP could come in handy would be when you're returning a reference to a mutable structure that you don't want the receiver to modify. Being able to transparently wrap an instance of T in Immutable<T> or CopyOnWrite<T> or add some other equally imaginary aspect (such as the transaction handling thing that brought this whole conversation up, though tbh that bit kind of went over my head) to any arbitrary object could be really handy.

    If you think about how such a thing could be implemented, I think you'll see that the easiest way for the .NET platform to support AOP would be to add functionality to the VMVES to check an object's aspects every time a method, property, or field is accessed. Knowing the audience here, I can confidently say that everyone will agree that adding that to the .NET runtime would be a bad idea. However, with Roslyn adding syntax-tree level rewriting to the .net compiler (paging @tarunik), it seems safe to say that we will see compile-time AOP in C# pretty damn soon, if not already.


    Filed under: And then we can say good bye to INotifyPropertyChanged for good



  • Roslyn's definitely quite an interesting prospect... ;)



  • But when our hypothetical Lisp programmer looks in the other direction,
    at the .NET framework, he doesn't realize he's looking up. What he sees
    are merely weird languages. He probably considers them about equivalent
    in power to Lisp, but with all this other hairy stuff thrown in as
    well. Lisp is good enough for him, because he thinks in Lisp.

    🚎



  • @Buddy said:

    Lisp is good enough for him, because he thinks in (((())()((()()())())))

    But I see what you did there, Buddy.



  • @Buddy said:

    But when our hypothetical Lisp programmer looks in the other direction, at the .NET framework, he doesn't realize he's looking up. What he seesare merely weird languages. He probably considers them about equivalentin power to Lisp, but with all this other hairy stuff thrown in as well. Lisp is good enough for him, because he thinks in Lisp.

    Clojure's already been ported to the CLR ;)



  • I woke up in the middle of the night last night, thinking,

            public object Convert(object value, Type targetType, object parameter, string language)
            {
                var scale = GetScale(parameter);
    
                //if (value is int) return (int)value * scale;
                //if (value is long) return (long)value * scale;
                //if (value is float) return (float)value * scale;
                //if (value is double) return (double)value * scale;
                //if (value is decimal) return (decimal)value * (decimal)scale;
                //return value;
                return (dynamic)value * scale
            }
    

    I mean, ok this isn't the best example (although on the other hand, if I'd been writing it out properly, that would be over 20 lines of code I just replaced, which is always good for morale), but the point is I could have been doing multiple dispatch in C# for going-on 5 years now, I'm just an idiot.

    Now all I need is a (stringy) type that does javascript-like type conversion, for ease of xaml.


Log in to reply