typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting
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
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  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