> On Jul 29, 2014, at 12:02 PM, Christoph Martens <cmartensms at gmail.com> wrote:
> 
> 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: http://wiki.ecmascript.org/doku.php?id=harmony:typed_objects <http://wiki.ecmascript.org/doku.php?id=harmony:typed_objects>
> 
> 
> I realized that I don't know what to do if someone has code like this:
> 
> typeof uint8; // "undefined" in ES5
> 
> 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.

--Oliver


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140729/130a537e/attachment.html>

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.