• Kogasa
    link
    fedilink
    111 year ago

    Love the implications of this as a compile time alternative for reflection, really hope I never run into it personally though.

      • itsame
        link
        11 year ago

        I think the example movie is showing an anti-pattern of the usage. Showing its proper use case would have been much better. In Nick Chapas’ example the code is becoming unreadable. His “Hello world” code is invisibly replaced with something else. This makes it worse than goto. If I ever see one of my colleagues do this, I will have them removed from the team.

  • Perhyte
    link
    61 year ago

    So realistically, the interceptable method will always know which generator(s) will target it ahead of time, right? There’s no reason to put an [Interceptable] attribute on the method otherwise, after all. (In the video it seems like that’s not required in the current prototype, but I saw no mention of removing this in the issue discussion. Perhaps that check was just not implemented yet?)

    To me this seems like a very weird version of Lisp macros, with their implementation hidden away in those generator(s) and essentially comefroms hidden away in the generated code. Though I suppose this is technically more powerful than macros because the generators are presumably allowed to look not just at the call itself but at the code around a call.

    I suppose it’s mostly the comefrom-iness I dislike about it. Now the code could do something entirely different, without any indication at the call site (unless you have your IDE highlight this for you or something). I feel like this language feature would make it harder to keep a mental model of what’s going on in the code in my head, especially if it winds up getting used for things that actually change the behavior of the code (e.g. AOP) instead of just doing essentially “the same thing, but faster and without reflection”.

    I like that they’re working on stuff like this, but perhaps just not exactly like this.