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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
