Re: Removal of identifierless getters, setters, etc.

(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
fail).

> 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