W3C home > Mailing lists > Public > public-script-coord@w3.org > January to March 2012

Re: [WebIDL] Feedback on getter and setter attribute algorithms

From: Cameron McCormack <cam@mcc.id.au>
Date: Mon, 23 Jan 2012 16:46:51 +1100
Message-ID: <4F1CF44B.5070205@mcc.id.au>
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:

Received on Monday, 23 January 2012 05:47:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:05 UTC