What is holding back Decorators ?
I'm not from TC39, but I can hazard a guess.
Decorators are somewhat useless without data properties to modify. Currently, class-fields is the proposal du jour, but even while in stage 3, it has issues, requiring trade-offs that many have voiced an unwillingness to accept. The awful syntax is forgivable given the approach they've taken, so that's not the issue. There are alternatives, but for one reason or another that TC39 is somehow unable to concisely articulate beyond stating it to be a matter of preference in their consensus, the alternatives are not able to gain traction in the committee. Yet, the discussion continues with a slowly increasing number of dissenting opinions in the discussion board.
In either case, decorators will probably see an advancement once some version of data properties lands in ES. In fact, it will likely happen quickly since few if any have any real issue with the concept.
...but that's just my guess.
For understanding the current status, I think that the following documents will be helpful.
The note and slide for the 66th meeting of Ecma TC39 rwaldron/tc39-notes/blob/master/es9/2018-09/sept-26.md#decorators-stage-2-update, docs.google.com/presentation/d/1s9bu_Z0vWR9eR4TL_8LEOmIFZvPth9Z8BLcHVqYWf_0/edit#slide=id.p
The slide for the 67th meeting of Ecma TC39 docs.google.com/presentation/d/12QtzhGvtA4bf7tznPzIeYH5aLEo40Kwfs3vpJxaSbHE/edit#slide=id.p
Thanks. I am looking forward to see progress on January then.
Best
On Tue, Dec 4, 2018 at 6:21 AM 森建 <moriken at kimamass.com> wrote:
For understanding the current status, I think that the following documents will be helpful.
Thanks!
The slide for the 67th meeting of Ecma TC39
docs.google.com/presentation/d/12QtzhGvtA4bf7tznPzIeYH5aLEo40Kwfs3vpJxaSbHE/edit#slide=id.p
For any who, like me, ran into a 404 following the "Improved Docs" link in those slides (which isn't a link to improved docs, it's to a discussion about improving docs), it's a minor typo in the URL. The correct one is: littledan/js-outreach-groups/blob/master/educators/notes-2018-10-11.md
-- T.J. Crowder
Thanks for the links T.J. I'm glad to see they're going forward with
decorators though I'm a bit confused as to why they'd want to do @dec export. That makes it look like the export directive is the target of
the decorator. Weird.
There was something I saw that disturbed me deeply.
DH: I think this is so zerosum that we can't progress. *I'd rather ship
the worst outcome than not ship.*
I could understand that position if it were a case of providing for something that cannot be done currently. Then it would be like saying "I'd rather feed them gruel than see them starve." However, whether it's private fields or decorators, there are already sufficient means of providing for these. In this situation, that statement seems to read more like "I know they ordered electric screwdrivers, but ship these butterknives instead; it takes too long to get the screwdrivers." While I know in my head that this can't possibly be the case....
FWIW I agree @dec export is a huge nonsense and it looks from the outside decorators are stuck due features creep ... it's like not releasing classes at all until all other PL gotchas and features are solved, which is not what happened in 2015.
Yet curious to see progress on what's being promoted as the universal solution to pretty much everything these days.
On Tue, Dec 4, 2018 at 3:47 PM Ranando King <kingmph at gmail.com> wrote:
Thanks for the links T.J.
Not me, it was 森建. I just supplied the corrected broken link from the slides.
...though I'm a bit confused as to why they'd want to do
@dec export. That makes it look like theexportdirective is the target of the decorator. Weird.
On Tue, Dec 4, 2018 at 4:00 PM Andrea Giammarchi <andrea.giammarchi at gmail.com> wrote:
FWIW I agree @dec export is a huge nonsense...
I agree with both of you. If the decorator decorates the class, it should
be after export, not before. I'm sorry if that means that there is a
bunch of code written with earlier Stage 1- and Stage 2- versions of
decorators that did it the other way, but that's not nearly a good enough
reason (IMHO) to do something so clearly non-intuitive and that breaks
parallel construction. RIght now, you say "If you want to export X, you put
export in front of it" (in the simple case). Breaking that for decorated
classes seems like a horrible idea.
TC39 is meeting this week. Here's hoping they come to resolution on this stuff and, as is usually the case, a good one that makes sense.
-- T.J. Crowder
(TC39 met last week)
I'd suggest filing an issue on the proposal repo for decorators, since that's where the proposal's champions will be most likely to respond.
On Tue, Dec 4, 2018 at 7:00 PM Jordan Harband <ljharb at gmail.com> wrote:
(TC39 met last week)
Doh! They're all blurring together! :-)
I'd suggest filing an issue on the proposal repo for decorators...
I believe there already is one: tc39/proposal-decorators#69
I'm off for a very thorough read, suggest others who care about @dec export ... vs. export @dec ... do the same. Probably any objections
we have have been raised and considered, but we can at least be
informed, vote on comments (don't know if that's significant, but
hey), and if appropriate, comment further. But it all starts, to my
mind, with that thorough read, and respect for those who've been in
this trench for some years now. :-)
-- T.J. Crowder
On Tue, Dec 4, 2018 at 7:08 PM T.J. Crowder <tj.crowder at farsightsoftware.com> wrote:
I believe there already is one: tc39/proposal-decorators#69
Apparently there was a poll (really wish someone had mentioned it here, following ALL contributors to proposals on twitter is not scalable): twitter.com/littledan/status/1050815837962158080
The @dec export got 36% vs. export @dec at 22 with 29% saying they don't care which.
-- T.J. Crowder
It's well known that twitter users pay a lot of attention to details, vote only once they've understood the issue and their own opinions about technical matters, and follow closer this channel since ever ...
Btw, I don't care 'cause I find the inline syntax to export a class ugly in either ways so I hope that is not a blocker 'cause I don't see it a real blocker in the real world, while not having decorators is a real issue in the real world.
Thanks for moving forward.
Best
Supposed to land in ES2016, decorators haven't moved from Stage 2 for more than a year now.
In various other discussions everyone has the easy "use decorators" answer for any problem, and yet no browser ships decorators, and no stage 3 is happening neither.
Is there already a better replacement or we're not convinced already that decorators are needed, when these are the first answer to any language extension proposed in this list?
Thanks in advance for any sort of clarification.