3 ms·

I do not like decorators. There, I said it. I'm all about a rational tech discussion, but I'm gonna put on my hater hat and say I think the syntax is stinky and

I do not like decorators. There, I said it. I'm all about a rational tech discussion, but I'm gonna put on my hater hat and say I think the syntax is stinky and I cringe when I look at a codebase littered with a smattering of side-effect labels. I know this is a superficial criticism so I will concede to those that have seen elegant use of decorators in action, I learn something new every day so perhaps I'll see the light eventually.

syntheticcdo 5y ago
In a current project, to support the "mix-in" style of development that decorators provide, I am preferring to extend the base class at class definition time, ie: class Example extends mixin(BaseClass) {} as opposed to the decorator style: @mixin class Example extends BaseClass {} If you dislike decorators, what are your thoughts on this style of code?
BulgarianIdiot 5y ago
Decorators don't work like annotations. They're functions applied to the function (or class) under them. As such, I find them much more direct and logical (and debuggable). Can you use them poorly? Sure, but this applies to anything. I.e. how is a decorator like this: @dec class Foo {...} Different than this? let Foo = dec( class Foo {...} ); It seems the same to me (mostly). The above has a better syntax.
- chii 5y ago
  decorators are better because of scoping imho.
- tobr 5y ago
  > They're functions applied to the function (or class) under them. Now that’s wrong. Decorators don’t work on functions, just methods. Which is ironic if you think about it, because if you program with functions you already have the tools you need to compose things, no need to invent some syntax sugar like this. For some reason object oriented programmers don’t seem to think like that. They want a special name and special syntax for everything.
  - saurik 5y ago
    Yeah: in a very real sense the "original sin" here was introducing (nay: forcing) class syntax to JavaScript, a language which at its core doesn't even naturally use/model classes (as it was designed around prototypes); all of this other complexity is the language falling downhill in an attempt to merely regain functionality for this new syntax that was previously trivial when you simply assigned "methods" directly to your prototype with the = operator (and so making it obvious where you would add a normal function call to functionally compose behaviors instead of needing a "decorator").

syntheticcdo 5y ago

In a current project, to support the "mix-in" style of development that decorators provide, I am preferring to extend the base class at class definition time, ie: class Example extends mixin(BaseClass) {} as opposed to the decorator style: @mixin class Example extends BaseClass {} If you dislike decorators, what are your thoughts on this style of code?

BulgarianIdiot 5y ago

Decorators don't work like annotations. They're functions applied to the function (or class) under them. As such, I find them much more direct and logical (and debuggable). Can you use them poorly? Sure, but this applies to anything. I.e. how is a decorator like this: @dec class Foo {...} Different than this? let Foo = dec( class Foo {...} ); It seems the same to me (mostly). The above has a better syntax.

chii 5y ago
decorators are better because of scoping imho.
tobr 5y ago
> They're functions applied to the function (or class) under them. Now that’s wrong. Decorators don’t work on functions, just methods. Which is ironic if you think about it, because if you program with functions you already have the tools you need to compose things, no need to invent some syntax sugar like this. For some reason object oriented programmers don’t seem to think like that. They want a special name and special syntax for everything.
- saurik 5y ago
  Yeah: in a very real sense the "original sin" here was introducing (nay: forcing) class syntax to JavaScript, a language which at its core doesn't even naturally use/model classes (as it was designed around prototypes); all of this other complexity is the language falling downhill in an attempt to merely regain functionality for this new syntax that was previously trivial when you simply assigned "methods" directly to your prototype with the = operator (and so making it obvious where you would add a normal function call to functionally compose behaviors instead of needing a "decorator").