W3C home > Mailing lists > Public > public-script-coord@w3.org > October to December 2010

Re: Removal of identifierless getters, setters, etc.

From: Cameron McCormack <cam@mcc.id.au>
Date: Thu, 14 Oct 2010 16:20:32 +1300
To: Garrett Smith <dhtmlkitchen@gmail.com>
Cc: public-script-coord@w3.org
Message-ID: <20101014032032.GI2585@wok.mcc.id.au>
(Note that the issue raised here is just whether Web IDL should drop
support for getters etc. with no identifier, i.e. ones that don’t also
cause a function to exist on the prototype (like namedItem).)

Garrett Smith:
> I recall reading that document, e.g. "sequence is a JS array, array is
> a host object" -- which jumped out at me at the time (because it is
> false).

Might’ve been poor scribing – this could have been referring to the fact
that IDL sequence<T> types are represented as JS Array objects while IDL
T[] array types are represented by a special “array host object”.  (As
currently specified.)

> The "getter" "setter" in WebIDL is what is known as "catchall" in
> ECMAScript[0]. It exists in browsers (as shown in some of the linked
> examples), but it's not standard and has some problems (see Waldemar's
> explanation on the proposal page[0]).
> The problems are easily seen in with "has" checks e.g. "in" operator,
> Array.prototype.indexOf, etc. I've been over this a few times already
> on whatwg et al so I'll be brief and share some links with those
> examples and explanations.

Web IDL currently requires real properties to be set on objects with
getters/setters.  So that should make “in” work as you would expect it
to on native objects.

Special “catchall” behaviour is still required in [[DefineOwnProperty]]
(primarily for type conversion to the setter’s argument type) and
[[Delete]] (basically just to give the deleter definition a chance to

> Mark Miller's also looked into this[4]:
> | Catchalls are an excellent example issue for both points, in opposite
> | directions. Regarding the second point, yes, we believe that new host
> | APIs should generally seek to avoid requiring catchalls, since new
> | native (i.e., written in EcmaScript) APIs must, and since there are
> | many benefits to being able to emulate more host APIs more easily in
> | EcmaScript (such as the ability to interpose intermediary wrappers).
> | Regarding the first point, since legacy host APIs do require
> | catchalls, EcmaScript must eventually too. The definition of how
> | WebIDL-expressed catchalls map to future EcmaScript should co-evolve
> | with the changes to EcmaScript needed to support this mapping.
> Seems pretty obvious to me.

I will of course be happy to cast getters/setters in terms of proxies or
catchalls or whatever ends up being standardised by TC39.

Cameron McCormack ≝ http://mcc.id.au/
Received on Thursday, 14 October 2010 03:21:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:43 UTC