It's disconcerting to hear that some at TC39 are pushing back against decorators. @BrendanEich please tell me these rumors are unfounded nonsense. The major projects using decorators is endless, as is the pain of this feature being forever in limbo.
-
-
Replying to @AdamRackis @BrendanEich
I am personally optimistic about moving decorators, but it does seem like there's endless demands to relitigate whether the feature is "well motivated" despite this already being decided when we advanced the stage 2. Other features don't have to prove themselves this often.
3 replies 1 retweet 9 likes -
Replying to @wycats @BrendanEich
It is literally inconceivable to me that anyone remotely familiar w/ the current JS ecosystem could conclude decorators are not "well motivated" I can't help but wonder if some people have idiosyncratic opinions against this feature, and are manufacturing opposition therefrom.
2 replies 2 retweets 6 likes -
What are the arguments against it? Why isn't it "well motivated"?
2 replies 1 retweet 0 likes -
Replying to @satya164 @AdamRackis and
The only thing I can think of: Decorators make code nearly impossible to statically analyze and optimize, where attributes (like you might find in C#) do not.
3 replies 1 retweet 7 likes -
But attributes don't let you implement @nonconfigurable or change the meaning of private state (which cannot be changed on the outside via a framework since the private names cannot be seen outside the class definition).
1 reply 1 retweet 0 likes -
The only way this argument makes sense is if someone had their heart set of a very particular kind of optimization that relied on classes being *considerably* more static than any other part of JS.
2 replies 0 retweets 3 likes -
But many of the arguments for why attributes are good enough (and in fact the result in Java) is that frameworks can still do the dynamic stuff when wiring things up. Decorators at least give TS a hint something is going on.
2 replies 1 retweet 2 likes -
It is worth pointing out that decorator behavior, as dynamic as they are, can still be verified staticallly. The TypeScript compiler today checks that a decorator does not remove properties from a declaration, or change its type in an incompatible way.
3 replies 1 retweet 5 likes
And the new style of decorators can even encode that kind of information in the signature of the decorator function itself.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.