4 ms·

Decorators are one of those things that I've not seen a use case that sells them to me. Like... I'm sure one day I'll see something and it'll just click, but n

Decorators are one of those things that I've not seen a use case that sells them to me. Like... I'm sure one day I'll see something and it'll just click, but not there yet.

saghm 9y ago
I'm the same way, except less sure that I'll find something that will change my mind.
- abritinthebay 9y ago
  Maybe “sure” was overly optimistic. “Hopeful” might be better put. I like the idea but I’ve yet to see a case that leads to better Code than other implementations.
solidr53 9y ago
https://mobx.js.org/best/decorators.html https://mobx.js.org/best/decorators.html
- abritinthebay 9y ago
  That... doesn't help. From what I see there I get harder to follow, non-idiomatic to anything in JS, code but the bonus is a terser syntax? Great...? I really hope there's a better use case for them because this is not selling me. Literally none of that post is a compelling case. I get the cleaner syntax, that's nice, but it also means now I have to look up what that does. And that decorated properties example? Yikes that's awful - it looks like a code-smell frankly. But all that initial urrrgh factor could be removed by showing me a use case that makes the code significantly more elegant to do `@foo bar` rather than `foo(bar)`.
danielbarla 9y ago
Well, in C#-land, we often use / abuse attributes to get information about a class or property at runtime. This way, framework or library code can inspect entities that you've authored, and dynamically deal with them. Perhaps a decent example is validation, where a declarative style has gained a lot of popularity. A JS example might be: @required firstName; This simply declares the intent / rule, but does not provide the implementation. We can argue terseness vs verbosity, implicitness vs explicitness all day - I'd argue that for certain basic things that you do highly frequently, a terse and implicit style is not a bad thing. It tends to increase the signal-to-noise ratio of your code, allowing the developer to focus on things that really are interesting, and not have to read through a lot of boilerplate.
- abritinthebay 9y ago
  Hmmm a required flag is a nice idea (but better exposed using interfaces as an idiom I’d argue) but it’s not selling me on the wider use case. If we were talking about very basic things then yes, sure, but I’d also argue that if they are truly basic then we could restrict decorators to built-in ones only (as those are the basics). Much like there are “magic” Symbols like Symbol.iterator.
  - danielbarla 9y ago
    That's interesting. My knowledge of JS is a bit lacking, so I'm struggling to see the equivalence of the interfaces approach. E.g., is it possible to parametrize interfaces with actual values, such as @maxLength(20)? Also, how do you apply interfaces down to the field-level, where they are of primitive types, such as number or string?
    - abritinthebay 9y ago
      That feels like a job for getters/setters, no?
      - danielbarla 9y ago
        I guess it depends what style you favour. I can't imagine using getters/setters like that in JS today, and not have major pains from it (things like not being able to use data binding frameworks easily, etc).
Matthias247 9y ago
In angular2 they are for example used for dependency injection, which works really well. Other use cases that I see are for example automatically generating [de]serialization code for members based on decorators and their values (like how Annotations are used in C# and Java serialization frameworks or tags in Go). There are also web frameworks popping up which use decorators for routing and parameter binding in a similar fashion how some Java frameworks work.
- abritinthebay 9y ago
  So syntax to his bad application design & code patterns behind? That’s an argument against them surely?
mmargerum 9y ago
When marshaling classes in and out of xml/json decarators can be added to properties to change the name of the equivalent Json field value as well as indicating if it's optional or not. Orms use decators to map object to relational tables the may have different field names, expressing key values, etc
- abritinthebay 9y ago
  None of that sounds particularly hard, complex, or tricky without decorators though. Like, I get they can be used for stuff but why are they a better option? So far - based on the responses here - it appears to be syntax for syntax sake and no practical benefit.
  - mmargerum 9y ago
    It's just sugar but it's less code and I find it easy to read at least in go.
    - abritinthebay 9y ago
      It’s not really less code though. It’s about the same but with an syntax that obfuscates where the logic happens. Terse at the usage point yes, but it swaps clarity for brevity. A sometimes useful trade off to be sure but... not sure I’ve seen any demonstration of benefits here.

Decorators are one of those things that I've not seen a use case that sells them to me. Like... I'm sure one day I'll see something and it'll just click, but not there yet.

saghm 9y ago

I'm the same way, except less sure that I'll find something that will change my mind.

abritinthebay 9y ago
Maybe “sure” was overly optimistic. “Hopeful” might be better put. I like the idea but I’ve yet to see a case that leads to better Code than other implementations.

solidr53 9y ago

https://mobx.js.org/best/decorators.html https://mobx.js.org/best/decorators.html

abritinthebay 9y ago
That... doesn't help. From what I see there I get harder to follow, non-idiomatic to anything in JS, code but the bonus is a terser syntax? Great...? I really hope there's a better use case for them because this is not selling me. Literally none of that post is a compelling case. I get the cleaner syntax, that's nice, but it also means now I have to look up what that does. And that decorated properties example? Yikes that's awful - it looks like a code-smell frankly. But all that initial urrrgh factor could be removed by showing me a use case that makes the code significantly more elegant to do `@foo bar` rather than `foo(bar)`.

danielbarla 9y ago

Well, in C#-land, we often use / abuse attributes to get information about a class or property at runtime. This way, framework or library code can inspect entities that you've authored, and dynamically deal with them. Perhaps a decent example is validation, where a declarative style has gained a lot of popularity. A JS example might be: @required firstName; This simply declares the intent / rule, but does not provide the implementation. We can argue terseness vs verbosity, implicitness vs explicitness all day - I'd argue that for certain basic things that you do highly frequently, a terse and implicit style is not a bad thing. It tends to increase the signal-to-noise ratio of your code, allowing the developer to focus on things that really are interesting, and not have to read through a lot of boilerplate.

abritinthebay 9y ago
Hmmm a required flag is a nice idea (but better exposed using interfaces as an idiom I’d argue) but it’s not selling me on the wider use case. If we were talking about very basic things then yes, sure, but I’d also argue that if they are truly basic then we could restrict decorators to built-in ones only (as those are the basics). Much like there are “magic” Symbols like Symbol.iterator.
- danielbarla 9y ago
  That's interesting. My knowledge of JS is a bit lacking, so I'm struggling to see the equivalence of the interfaces approach. E.g., is it possible to parametrize interfaces with actual values, such as @maxLength(20)? Also, how do you apply interfaces down to the field-level, where they are of primitive types, such as number or string?
  - abritinthebay 9y ago
    That feels like a job for getters/setters, no?
    - danielbarla 9y ago
      I guess it depends what style you favour. I can't imagine using getters/setters like that in JS today, and not have major pains from it (things like not being able to use data binding frameworks easily, etc).

Matthias247 9y ago

In angular2 they are for example used for dependency injection, which works really well. Other use cases that I see are for example automatically generating [de]serialization code for members based on decorators and their values (like how Annotations are used in C# and Java serialization frameworks or tags in Go). There are also web frameworks popping up which use decorators for routing and parameter binding in a similar fashion how some Java frameworks work.

abritinthebay 9y ago
So syntax to his bad application design & code patterns behind? That’s an argument against them surely?

mmargerum 9y ago

When marshaling classes in and out of xml/json decarators can be added to properties to change the name of the equivalent Json field value as well as indicating if it's optional or not. Orms use decators to map object to relational tables the may have different field names, expressing key values, etc

abritinthebay 9y ago
None of that sounds particularly hard, complex, or tricky without decorators though. Like, I get they can be used for stuff but why are they a better option? So far - based on the responses here - it appears to be syntax for syntax sake and no practical benefit.
- mmargerum 9y ago
  It's just sugar but it's less code and I find it easy to read at least in go.
  - abritinthebay 9y ago
    It’s not really less code though. It’s about the same but with an syntax that obfuscates where the logic happens. Terse at the usage point yes, but it swaps clarity for brevity. A sometimes useful trade off to be sure but... not sure I’ve seen any demonstration of benefits here.