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

David Bruant bruant.d at gmail.com
Sat Aug 3 03:01:05 PDT 2013


Le 03/08/2013 02:59, Brendan Eich a écrit :
> 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.
>
> s/way/do/ ?
s/way/weigh. I felt something was wrong with this sentence, but couldn't 
put the finger on it.

> You could be right. We know lexical composes best, so I'm reworking 
> the proto-strawman based on Jasvir's feedback.
for non-null too, I hope? Otherwise this is asking for non-compatible 
libraries for the built-in new value types

>>> 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. 
I understand now how I had misunderstood your words (in the context you 
put them and in this context where I mistakenly reused them). In any 
case, they applied only for the dynamic Function.setTypeOf.


>>> 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.
oh ok. That makes much more sense now. Then the restore step is optional.
I don't see the benefit of that against a file/function-wise directive.

For both null and the new value types, I'm still unclear on why could 
devs would choose something different than the default. I feel the 
incentives can only way in favor of keeping the default. I'm interested 
in what other devs think.

David


More information about the es-discuss mailing list