"use es6"; Any plans for such a mode?
On Jul 29, 2014, at 12:02 PM, Christoph Martens <cmartensms at gmail.com> wrote:
This code will be valid in an ES5 environment, because uint8 is an undefined reference/variable. But as uint8 is a built-in value type, what should happen in an ES6 environment?
uint8 is not a value of type uint8, it's the name of the type itself so presumably it will return "object" or some such (i haven't read structural type spec yet). Anyway, this typeof check is used to identify support for the API rather than anything else.
I'm also opposed to adding yet another mode switch, as just "use strict" has added complexity throughout JSC, and has minimal benefit. This would have even less benefit than that, I think the problem here is that you're assuming a lot more static inference than actually occurs - JS is a dynamic language so most performance/correctness work is performed dynamically as it is unavoidable.
Christoph Martens wrote:
Also, you could solve the typeof null; problem with such a thing without invalidating legacy code.
You missed the whole previous lifetime many of us lived :-P.
esdiscuss.org/topic/es6-doesn-t-need-opt-in (1JS o.p. -- note that some aspects are out of date)
esdiscuss.org/topic/use-strict-2 (just one of many rehashes)
www.google.com/search?q="versioning+is+an+anti-pattern" (good in general)
It's not clear whether you were proposing
use es6;
or
"use es6";
but I think you meant the latter -- yet that would be ignored by pre-ES6 implementations under the hypothesis, so typeof null would still have to be "object".
There's no issue with typeof uint8 changing across implementation versions. Indeed typeof is one way to "object-detect" and fall back on a shim (if possible), AKA polyfill.
Thanks for the links, those cleared up pretty much what I had in mind.
On the other hand that means typeof uint8 won't return a primitive value, right? Meaning typeof uint8 should return "object", so a theoretical Polyfill (or binding in my case) should have the prototype pointing to Object?
global.uint8.prototype = Object; // ?
Christoph Martens wrote:
On the other hand that means typeof uint8 won't return a primitive value, right? Meaning typeof uint8 should return "object", so a theoretical Polyfill (or binding in my case) should have the prototype pointing to Object?
That's not decided, and polyfilling uint8 is hard. Stay tuned on value types/objects futures, ES7 is still being worked on.
An HTML attachment was scrubbed... URL: esdiscuss/attachments/20140730/4c3df3d1/attachment
Hey all,
I just read a bit about the ParallelJS project, Typed Objects (StructType) and was curious if I could implement bindings for v8 today.
Link to wiki document: harmony:typed_objects
I realized that I don't know what to do if someone has code like this:
typeof uint8; // "undefined" in ES5This code will be valid in an ES5 environment, because uint8 is an undefined reference/variable. But as uint8 is a built-in value type, what should happen in an ES6 environment?
My ideas so far:
Why not offer something like "use es6"; to offer the same behaviour in supported environments? Are there any plans for such a thing? JIT implementors could then easily trace if the code was built for ES6 and optimize their static code analysis heuristics.
I mean, "use strict" is pretty cool, but it has the problem that it will be available among multiple future versions. "use es6" would be an identifier a JIT can validate against a specification directly.
Also, you could solve the typeof null; problem with such a thing without invalidating legacy code.