To elaborate on the ThisMode scenario, take the following example (also
available at https://gist.github.com/4401538):
var value = 10;
module X {
// implicit "use strict"
var value = 20;
export class Builtin {
constructor(){
if (this == null) {
// what global am I?
}
}
method(){
if (this == null) {
// what global am I?
return value;
}
}
}
}
module Y {
// implicit "use strict"
var value = 30;
var global = this;
var x = new X.Builtin;
export function getValue(){
return x.method.call(null);
}
}
console.log(Y.getValue());
I'm fairly sure in a userland code scenario the result should be 20. My
concern was whether any code in the ES6 stdlib is `this` sensitive in such
a way that either `value` should be either 10 or 30. I haven't identified
any in which it should be, but I'm not confident none such example exists.
On Fri, Dec 28, 2012 at 10:17 AM, Brandon Benvie
<[email protected]>wrote:
> I ave to recant on this after having doing some research (and actually
> making it work). The original reason about ThisMode may still be true but
> I'm less sure. It was basically about being unable to identify the correct
> global `this` in strict mode since its not automatically provided for you,
> and multiple global is now a common thing in es6, but I don't think this
> ended up gmpering anything in actual usage.
>
> The other reason was because of ThrowTypeError, which requires a.) adding
> multiple accessor own properties to every function object, and b.) modified
> GetOwnProperty semantics. Upon inspection, I couldn't actually find
> anything in the spec that prohibits builtin functions from having those
> ThrowTypeError accessors like I had originally supposed there was. In my
> implementation I cheat and use magic to remove them even though the
> functions are compiled as strict (they're in implicit module bodies) but I
> now realize that's not necessary, at least to be spec compliant.
>
> On Thursday, December 27, 2012, David Bruant wrote:
>
>> Le 27/12/2012 02:52, Brandon Benvie a écrit :
>>
>>> As an aside, ES itself can't self-host its own builtins in strict mode
>>> because of the (two of the very few) semantic differences that exist
>>> between strict mode and non-strict mode: non-strict thrower properties
>>> (which I've come to consider an annoying blight that punishes developers in
>>> order to influence implementers) and strict this-mode differences. Every
>>> semantic difference you mandate furthers this gap.
>>>
>> I fail to understand why built-ins can't be implemented in strict mode.
>> Can you provide a concrete example of something that can't?
>>
>> Thanks,
>>
>> David
>>
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
