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鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix class inheritance in IE10 #7969
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some fixtures need to be updated
subClass.prototype = Object.create(superClass && superClass.prototype, { | ||
constructor: { | ||
value: subClass, | ||
enumerable: false, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It could be better to omit enumerable: false
just to not force sham implementations to throw, but this would only happen on IE<9 anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the spec inherits. I think changing it to be enumerable would break more people who use a for-in.
You can always use loose mode to support these IE9?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think they just mean that the default is already false
anyway, so leaving it out doesn't make anything fail, but allows polyfills to be less agressive in requiring enumerability on older platforms.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ahh, ok.
|
||
test() { | ||
} | ||
Object.defineProperty(Obj.prototype, 'test', { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand what caused this change. Any idea? It doesn't seem like this should be split off like this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the reason I filled #7771. jridgewell@ab403f3#diff-0cd85dd4813df0687b8938547953d585L24
test
here will be set on the subclass, but the super defines a get test
, so it'll throw.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ahh got it.
}; | ||
_getPrototypeOf = Object.setPrototypeOf | ||
? Object.getPrototypeOf | ||
: function _getPrototypeOf(o) { return o.__proto__; }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I'd still want to fall back to Object.getPrototypeOf
if __proto__
falsy, since that was the old behavior.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
2ebaafb
to
ee384fe
Compare
Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/8054/ |
_getPrototypeOf = Object.getPrototypeOf; | ||
} else { | ||
_getPrototypeOf = function _getPrototypeOf(o) { | ||
return o.__proto__; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think my comment here was misinterpreted. My concern was that this does not preserve the behavior changed in https://github.com/babel/babel/pull/7675/files#diff-a6fddd06921a2b0da9eb1fb68cd794b9L14
Old super calls used to be (Foo.__proto__ || Object.getPrototypeOf(Foo)).call
, but here we assume that __proto__
is the source of truth and will always have a value, instead of falling back to Object.getPrototypeOf
of __proto__
is falsy.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wow, that was dyslexic of me. Fixed.
a1a1fe2
to
5e3306a
Compare
How soon can this be released? Meteor implemented a pretty nasty workaround for this, which I would love to revert before shipping Meteor 1.7. I would have reported the problem, but it looked like Babel had simply decided to drop support for IE10, so I didn't think you'd be open to it. |
@benjamn Likely tomorrow. What's your timetable for 1.7? |
Tomorrow is great. We're on RC 11 right now, but I think this is a good reason to wait a little longer! I'm giving a talk at Meteor Night next Wednesday, with a call-to-action to update to Meteor 1.7, so we'd better release Meteor 1.7 before then, but I suppose we can just ship the workaround if the next Babel beta somehow doesn't get released by then. |
This reverts commit 8bfdea7. As clever as this IE10 hack may have been, it should no longer be necessary, thanks to babel/babel#7969. cc @abernix @hwillson
This reverts commit f8ab946, and unfixes #7771, because of IE 10. 馃槱
Also updates the
getPrototypeOf
helper according to #7965 (comment).Fixes #7892.
Fixes #7965.