Turn the pref for public fields on by default
Categories
(Core :: JavaScript Engine, task, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox69 | --- | fixed |
People
(Reporter: khyperia, Assigned: jorendorff)
References
Details
(Keywords: dev-doc-complete)
Attachments
(2 files)
There's not really any actual work to do here: this is a tracking bug for the release of public fields.
See the depends-on list of bug 1499448 to assess what remaining work there is. The tree view is particularly helpful.
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 1•4 years ago
|
||
Assignee | ||
Comment 2•4 years ago
|
||
Depends on D34638
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 3•4 years ago
•
|
||
Public fields are a JavaScript language feature that's used in classes.
class Car {
make = "Ford";
model = "Prefect";
wheels = [0, 0, 0, 0];
}
let myCar = new Car; // {make: "Ford", model: "Prefect", wheels: [0, 0, 0, 0]}
We implement only the public fields described in this proposed specification. No private fields yet.
Comment 4•4 years ago
|
||
Do you know if there should be some devtools support for this?
I can't think of anything specific, but maybe I'm missing something.
Thanks
Assignee | ||
Comment 5•4 years ago
•
|
||
Try
- stepping over the
class Car
declaration; - stepping into
new Car
and stepping over each assignment
and see if the behavior is reasonable.
Unfortunately, I think it will probably be ugly and hard to fix. :-\
Assignee | ||
Comment 6•4 years ago
|
||
https://treeherder.mozilla.org/#/jobs?repo=try&revision=4a8e776762d22867691ea1f93630e540596eff9a
Pushed by jorendorff@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/d7e33c843b24 Part 1: Turn the pref for public fields on by default. r=khyperia https://hg.mozilla.org/integration/autoland/rev/8227f5fbbe20 Part 2: Enable fields by default in the JS shell. r=khyperia
Pushed by jorendorff@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/9e789088540d Part 2: Enable fields by default in the JS shell. r=khyperia
Comment 9•4 years ago
|
||
bugherder |
Jason/Ashley, is --disable-experimental-fields worth testing? (if so, it should probably be in fuzz-flags.txt)
Sidenote, --enable-experimental-fields got removed here...
Reporter | ||
Comment 11•4 years ago
|
||
In my opinion, probably not? I'm not 100% sure of why we keep the flag in, I'm assuming it's a last resort backup plan to disable things if everything explodes? So it's not going to stay relevant for long, once the feature has rode all the way to release.
Assignee | ||
Comment 12•4 years ago
|
||
Agreed, it's only there as a last resort backup plan.
I would not bother fuzz-testing this.
Assignee | ||
Comment 13•4 years ago
|
||
Gary, note that I'm going to do the same thing to --enable-experimental-await-fix later this week, over in bug 1558971.
Got it, thanks! (I won't bother with these flags then, just clarifying...)
Comment 15•4 years ago
|
||
Compat data updated: https://github.com/mdn/browser-compat-data/pull/4711
Added to release notes: https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/69#JavaScript
Classes page mentions it: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes#Field_declarations
New page on class elements lives here: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes/Class_elements
Description
•