Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

build: disable harmony classes #272

Merged
merged 2 commits into from
Jan 9, 2015

Conversation

bnoordhuis
Copy link
Member

The V8 development branch has unshipped ES6 classes pending resolution
of a number of inheritance edge cases. Disable classes in io.js for
the sake of feature parity.

See #251 for background and
discussion.

R=@iojs/tc

@cjihrig
Copy link
Contributor

cjihrig commented Jan 9, 2015

LGTM

v8.setFlagsFromString('--harmony_classes');
eval('"use strict"; class C {}'); // Should not throw.
eval('"use strict"; let x = 42'); // Should not throw.
eval('"use strict"; const y = 42'); // Should not throw.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

afaik let and const are included under another patch, is there a really good reason to have them here? (Also, I thought those worked without strict?)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

--harmony_classes implies --harmony_scoping. The check is to ensure that the the latter is still on. I believe let/const in sloppy mode is still under development.

@bnoordhuis
Copy link
Member Author

I've added some comments to clarify the --harmony_classes/--harmony_scoping relationship and added another check. Can I have one more LGTM?

@domenic
Copy link
Contributor

domenic commented Jan 9, 2015

--harmony_object_literals behavior will be changing too. That should be disabled.

@bnoordhuis
Copy link
Member Author

@domenic What's the change and where was it announced? I didn't see anything on v8-dev.

@domenic
Copy link
Contributor

domenic commented Jan 9, 2015

harmony_object_literals is part of the classes implementation, which is why there's a dependency and why V8 unstaged them all together.

In particular, there are changes to super(), toMethod, and the resulting changes for concise methods in object literals. (There's also some non-public (ugh) discussion of an unrelated bug in the concise method implementation.)

@domenic
Copy link
Contributor

domenic commented Jan 9, 2015

In general, the fact that V8 unshipped both classes and object literal extensions in v8/v8@a417b41 should be taken as a loss of confidence in their implementation and I'd encourage iojs to follow those kinds of signals.

@bnoordhuis
Copy link
Member Author

Okay, I added a second commit that disables object literals. @domenic et al, PTAL.

@domenic
Copy link
Contributor

domenic commented Jan 9, 2015

LGTM, although as discussed in #251 my preferred approach would be to ship V8 3.30.33.14.

The V8 development branch has unshipped ES6 classes pending resolution
of a number of inheritance edge cases.  Disable classes in io.js for
the sake of feature parity.

See nodejs#251 for background and
discussion.

PR-URL: nodejs#272
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: Domenic Denicola <[email protected]>
Per the discussion in nodejs#272, upstream
V8 has disabled Harmony object literals for the time being.  Do the
same for feature parity.

PR-URL: nodejs#272
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: Domenic Denicola <[email protected]>
@bnoordhuis
Copy link
Member Author

@domenic Noted. I'll land this and I'll bring it up at the go/no go release meeting. Reverting the V8 upgrade is the work of minutes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants