Typeof this in getters (was: eval on non-strings)

Allen Wirfs-Brock allen at wirfs-brock.com
Tue Feb 28 14:04:54 PST 2012


On Feb 28, 2012, at 10:03 AM, Domenic Denicola wrote:

>> Specifically regarding ToObject.  It's use is important in minimizing the semantic differences between primitive values and Objects. In ES5 we eliminated the automatic wrapping of primitive values  used as this values in method invocations.  That means that in most cases 42 and (new Number(42)) can be used interchangeably. If we start leaving out ToObject calls in random places the distinction between a primitive value and a wrapped primitive values will start tripping people up.
> 
> This actually is apropos of something I'd been meaning to ask about. Consider the following JSFiddle:
> 
> http://jsfiddle.net/CxdMs/15/
> 
> It seems reasonably clear that the result for functions should be object (non-strict)/number (strict), according to section 10.4.3.

10.4.3 is the applicable section.  It get/set function is still "function code" so it doesn't matter what mechanism was used to call it.  It still has to pass through the 10.4.3 requirements.  So the correct answer is number/object.

Any other answer is not in conformance with the spec.  

There there should be test262 tests for this.  However I bet there aren't any, given that the two major contributors to the test suite appear to be out of conformance

Allen





> 
> But for getters, the major browsers disagree, and my spec-fu can't find anything besides the abovementioned section. Firefox and IE9 say object/object, while V8 says number/number. And at least one version of JavaScriptCore we have lying around says number/object. If someone could walk me through the spec correctly, I'd be happy to file appropriate browser bugs.
> 
> Note that this is a real-world issue. The Chai.js assertion library is trying to break free of V8 and become useful in browsers, but is encountering problems due to this behavior:
> 
> https://github.com/logicalparadox/chai/issues/32
> 
> Thanks all,
> Domenic
> 



More information about the es-discuss mailing list