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@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"
because
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 :-(
David
[1]
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions_and_function_scope/Strict_mode/Transitioning_to_strict_mode?redirectlocale=en-US&redirectslug=JavaScript%2FReference%2FFunctions_and_function_scope%2FStrict_mode%2FTransitioning_to_strict_mode
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
