W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2011

Re: [WebIDL] platform array objects

From: Cameron McCormack <cam@mcc.id.au>
Date: Fri, 19 Aug 2011 15:00:19 +1200
Message-ID: <4E4DD1C3.2080004@mcc.id.au>
To: andrew@ado.is-a-geek.net
CC: public-script-coord <public-script-coord@w3.org>
Thanks for your comments Andrew.

Andrew Oakley:
> http://dev.w3.org/2006/webapi/WebIDL/#es-array:
>> Platform array objects defy being fixed; if Object.freeze,
>> Object.seal or Object.preventExtensions is called on one, the
>> function MUST throw a TypeError.
> Can I ask why? I don't see any reason for this and it feels like it
> would make implementations more complicated. (This also seems to be
> present in the platform objects description.)

I think it makes implementations simpler -- then there is no need to 
define and handle what should happen to properties on a platform array 
object if it changes length.

> § Platform array object [[GetOwnProperty]] method says that the
> property descriptor for "length" whould have [[Configurable]] set to
> true. Later on we try to make sure it can't be deleted (§
> Would it not be easier just to make it not [[Configurable]]?

To be able to implement platform array objects with proxies, we need to 
expose configurable properties, since last I checked the Proxy proposal 
did not support exposing non-configurable properties.  If this has 
changed, then I agree we should make it non-configurable.

> The [[GetOwnProperty]] implementation also tries calling the normal
> version of [[GetOwnProperty]] at the end of the algorithm rather than at
> the start like Array and Arguments objects. I could agree with it being
> either way round, but it would be nice to be consistent with the
> ECMAScript spec.

Array objects don't have a specialised [[GetOwnProperty]] do they? 
Anyway for platform array objects, I don't think it matters too much, 
since there can never be a "real" own property named "length" or like 
one of the array index properties on an platform array object.

I think it looks cleaner as is, resolving the special properties first 
before looking at the regular properties, so I will leave it.

> Finally, we don't define what "Reject" means here (although we do define
> it for the "platform object" algorithms.

Good point, I've added some wording before the platform array object 
algorithms that use it.


If the above resolutions are satisfactory, could you please indicate so 
for the Disposition of Comments document I will need to assemble for 
this Last Call.


Received on Friday, 19 August 2011 03:01:05 UTC

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