On 29.07.2014 21:20, Brendan Eich wrote:
> 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.
>
> http://esdiscuss.org/topic/es6-doesn-t-need-opt-in (1JS o.p. -- note 
> that some aspects are out of date)
>
> http://esdiscuss.org/topic/use-strict-2 (just one of many rehashes)
>
> https://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.
>
> /be
>


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; // ?


~Chris

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?

```js
global.uint8.prototype = Object; // ?
```