typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting
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.
More information about the es-discuss