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