- From: Cameron McCormack <cam@mcc.id.au>
- Date: Mon, 23 Jan 2012 16:46:51 +1100
- To: David Bruant <bruant.d@gmail.com>
- CC: public-script-coord@w3.org
Hi David. David Bruant: > Both attributes getter and setter algorithms [1] do the following: > 1) Let O be the result of calling ToObject on the /this/ value. > 2) Throw a TypeError if the attribute was not defined with LenientThis > and O is not "a platform object that implements the interface on which > the attribute was declared" > > Under these conditions, I wonder if the ToObject is really useful. In > the case /this/ is a primitive value different than undefined or null, > it will create an object based on the value. If the attribute is not > declared with [LenientThis], it will throw a TypeError. It won't with > the [LenientThis], but the attribute value will relate to an object that > can't be reached anymore (since the object is created internally and not > exposed to the outside world). > > One idea would be that instead of the first "let O = ToObject(this)", a > TypeError could be thrown whenever /this/ is not of type Object (ES5.1 - > 8.6 definition). > The difference in semantics is that an error is thrown for all primitive > values (instead of just undefined and null) for [LenientThis] > attributes. I can only see this as a good thing since I can see a use > case for using primitive values as /this/. > > Is there some backward compatibility concern that could prevent this change? No, I think that change is fine to make. Done: http://dev.w3.org/cvsweb/2006/webapi/WebIDL/Overview.xml.diff?r1=1.450;r2=1.451;f=h
Received on Monday, 23 January 2012 05:47:32 UTC