typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting
brendan at mozilla.com
Fri Aug 2 17:59:10 PDT 2013
David Bruant wrote:
> 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.
You could be right. We know lexical composes best, so I'm reworking the
proto-strawman based on Jasvir's feedback.
>> 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."?
Sorry, you can't echo my words at me and win this argument. JS != SES.
We do not assume mutual suspicion among same-origin and transcluded
<script src=> scripts. Haven't for 17 years, won't start now.
>> 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.
The idea here is lexical scope, so the special forms compile to bindings
that lexically alter typeof results, but library code scoped outside
this extent is unaffected by these special forms.
More information about the es-discuss