Introducing smap.js, a forward polyfill for ES6 Maps
1–10 of 10 posts
Re: Introducing smap.js, a forward polyfill for ES6 Maps
#2 var NULL = null, TRUE = true, FALSE = false
Re: Introducing smap.js, a forward polyfill for ES6 Maps
#3var NULL = null, TRUE = true, FALSE = false I'm not sure I understand this. Why assign these to variables?
That is part of the es6-collections polyfill included as part of smap.js. If I understand correctly, it is for safety (for example you cannot override the value of "true").
Re: Introducing smap.js, a forward polyfill for ES6 Maps
#4var NULL = null, TRUE = true, FALSE = false I'm not sure I understand this. Why assign these to variables?
That is part of the es6-collections polyfill included as part of smap.js. If I understand correctly, it is for safety (for example you cannot override the value of "true").
null, true, and false are all keywords. Isn't undefined the only one that can be redefined? (And then it's just equal to void 0.)
Re: Introducing smap.js, a forward polyfill for ES6 Maps
#5var NULL = null, TRUE = true, FALSE = false I'm not sure I understand this. Why assign these to variables?
I think the reason for these is for js minification. With these assignments a simple minifier will replace those three variables with a line like this:
var a=null,b=true,c=false;
Re: Introducing smap.js, a forward polyfill for ES6 Maps
#6Earlier quoted context omitted.
That is part of the es6-collections polyfill included as part of smap.js. If I understand correctly, it is for safety (for example you cannot override the value of "true").
null, true, and false are all keywords. Isn't undefined the only one that can be redefined? (And then it's just equal to void 0.)
Yep, you're right. I forgot about that.
Re: Introducing smap.js, a forward polyfill for ES6 Maps
#7var NULL = null, TRUE = true, FALSE = false I'm not sure I understand this. Why assign these to variables?
I think the reason for these is for js minification. With these assignments a simple minifier will replace those three variables with a line like this: var a=null,b=true,c=false; Then your minified js will be smaller because all other instances of true, false and null will be one character. Whether or not this is a reasonable optimization is debatable but in terms of pure code size it would be a win.
Couldn't you build it into the minifier rather than polluting the original source?
Re: Introducing smap.js, a forward polyfill for ES6 Maps
#8I have quite a few questions about this implementation, but here are two bigger ones:
1. Why are constructed Maps here having delete, get, has, set, size, keys, values, and iterate added outside of the prototype? I guess I don't see why you wouldn't just put these on the prototype. That said, .call seems to be unnecessary in a lot of this code.
2. Why isn't there any attempt to make lookups for primitives faster. It's all O(n).
Re: Introducing smap.js, a forward polyfill for ES6 Maps
#9For anyone confused, like me, about what a forward polyfill is, here's an explanation:
Re: Introducing smap.js, a forward polyfill for ES6 Maps
#10Earlier quoted context omitted.
I think the reason for these is for js minification. With these assignments a simple minifier will replace those three variables with a line like this: var a=null,b=true,c=false; Then your minified js will be smaller because all other instances of true, false and null will be one character. Whether or not this is a reasonable optimization is debatable but in terms of pure code size it would be a win.
Couldn't you build it into the minifier rather than polluting the original source?
Yes, stuff like this shouldn't be in the source. UglifyJS and Closure compiler make this optimization, but I've used other js minifiers that did not.