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
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
