typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

David Bruant bruant.d at gmail.com
Fri Aug 2 16:53:20 PDT 2013

Le 30/07/2013 00:12, Brendan Eich a écrit :
> ๏̯͡๏ Jasvir Nagra wrote:
>> Unless I am really misreading your examples, I do not think the new 
>> proposal overcomes the problems of 
>> http://wiki.ecmascript.org/doku.php?id=harmony:typeof_null. If 
>> Function.setTypeOf dynamically affects subsequent use of typeof, then 
>> action-at-a-distance problems will persist.  If one library adopts 
>> one convention regarding typeof null and another a different one, 
>> then these libraries will not be useable together.
> Right, so don't do that
This is asking to never use any currently existing library. Fixing 
typeof null doesn't way enough and by a large factor.

> There's no assumption of hostile code here, as usual you have to trust 
> what you include into your single-frame/window (realm) TCB, etc.
"This is a human-factors / phenomenology->likelihood problem."?

> Le 30/07/2013 01:04, Brendan Eich a écrit :
>> Allen Wirfs-Brock wrote:
>>> I would argue that Functioun.setTypeOf(null, "null") is actually a 
>>> different kind of beast and one that you would want to be lexically 
>>> scoped. The difference is that it is changing the meaning of a 
>>> pre-existing operator applied to a pre-existing value. This 
>>> reinterpretation really does need to be scoped only to code that 
>>> wants to see that change.
>> Ok, good feedback between you and jasvir. This suggests using the 
>> syntax I mooted:
>>   typeof null = "null"; // lexically rebind typeof null
>>   new code here
>>   typeof null = "object"; // restore for old code after
I'm not sure I understand how it's different from Function.setTypeOf.
What happens if you don't restore? Does the rest of the program gets 
executed with typeof null === 'null'?
If, for whatever reason, one doesn't restore, it seems that the 
semantics of code starts depending on execution order (thinking of 
script at async). Something I would avoid and recommend other devs to avoid.
Also, all in all, I'd prefer Function.setTypeOf because it's deletable 
(like Object.prototype.__proto__)

Function.setTypeOf (or typeof null = 'whatever' assuming I understand 
the restore part right) is an ambiant capability that dynamically 
changes the whole-program semantics of typeof null.
I hope I made the dynamic flavour of the feature sound scary enough for 
it to be considered as a bad idea :-)

I'm tempted to say "directive or nothing".
But even as a directive, it's annoying as it makes code harder to read. 
In code, you'll almost never see:
     typeof x === "null"
     x === null
means the same thing and is shorter.
The only cases in code where the directive would make a change is:
     typeof x === 'object'
I imagine the mental burden to switch between some code using one 
behavior and some other code using another one will be big enough for 
people to think "fuck it! I'm going for the legacy behavior! That's the 
one people know and use anyway!"

If the things to think about when transitioning to strict mode [1] make 
a scale of annoying-ness, then typeof null would be placed in the worst 
category (semantic differences) and probably be the worst of these given 
that it's much more used than arguments, eval and 
this-in-non-OO-contexts (maybe combined). That makes transitionning code 
from old-typeof-null to new-typeof-null nothing be a nightmare.

I would love to see typeof null fixed or even fixable, but that probably 
takes a different language :-(



More information about the es-discuss mailing list