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

Brendan Eich brendan at mozilla.com
Sat Aug 3 11:44:59 PDT 2013

David Bruant wrote:
>>>>> 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.

Yes, but the example would want a block then:

     typeof null = "null";
     new code here

And yes, value objects would want a special form, but as I wrote,

   typeof int64 = "int64";

is not symmetric with RHS typeof, so we'd want something else, not too 
chatty, maybe

   typeof for int64 is "int64";

but as a special form, this requires evaluation of the expression int64, 
which must resolve to a value object factory function. And that 
(v.o.f.f.) needs to be defined first before noodling more with syntax.

> I don't see the benefit of that against a file/function-wise directive.

Lexical means block in the modern Harmony era.

> 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 [weigh] in favor of keeping the default. I'm 
> interested in what other devs think.

I'm not sure what you mean re: "new value types". They have no "default" 
and "object" fails usability and useful-invariant requirements.

For null, are you sure people won't choose to "repair" this "ES regret" 
? :-P


More information about the es-discuss mailing list