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

[Bug 26183] make it easier to define an iterator on an interface that iterates over a set of values

From: <bugzilla@jessica.w3.org>
Date: Fri, 19 Sep 2014 23:37:31 +0000
To: public-script-coord@w3.org
Message-ID: <bug-26183-3890-REcVmujB7K@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26183

--- Comment #14 from Tab Atkins Jr. <jackalmage@gmail.com> ---
(In reply to Domenic Denicola from comment #13)
> Right, what you want is indeed traits. Partially because subclassing to
> impose more restrictions is bad design, and partially because subclassing to
> impose more restrictions just plain doesn't work in JavaScript. (Unlike in
> other languages, where it's simply discouraged.)
> 
> There is really no way it makes sense, neither theoretically nor
> practically, to put Map.prototype in the prototype chain. The Map.prototype
> methods are not generic, so this case is very different from Array.

The Map.prototype methods *defined by authors/libraries* are generic.  WebIDL
can take care of defining that all the ES-defined methods are overridden
appropriately (and use a different data structure than the [[MapData]] from
Map, so you can't bypass any input restrictions by using Map.prototype.set).

> The correct thing to do here, instead of abusing the prototypal inheritance
> hammer, is to turn to other tools (whether they be some future version of
> traits, or just WebIDL).

WebIDL is a hammer we can use for language-defined things.  Inheritance is
currently the only hammer we can use for author-defined things.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Received on Friday, 19 September 2014 23:37:33 UTC

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