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: Wed, 17 Sep 2014 19:09:40 +0000
To: public-script-coord@w3.org
Message-ID: <bug-26183-3890-W624ecBrRy@http.www.w3.org/Bugs/Public/>

--- Comment #12 from Tab Atkins Jr. <jackalmage@gmail.com> ---
(In reply to Domenic Denicola from comment #11)
> > What do you feel about the prototype of such objects?
> I think they should definitely not inherit from the prototypes. They are
> "-like", not "is a".

I 100% disagree, though of course what we really want is Traits.

It's really dumb to have a bunch of things that are *similar to* Maps/Sets/etc,
but not actually Maps/Sets/etc, such that if you define new methods on Map
(like update(), or setdefault(), or other useful things from Python that JS
hasn't sprouted yet) they don't show up on the other Map-like things.

This is the same exact problem we had with Array-like things, where NodeLists
dont' have map/filter/etc and I'm constantly writing:

`function find(sel) {return

just so I can get a real fucking Array and call .map() on them.

There are sound theoretical reasons to not put Map.prototype in its prototype
chain, but in my opinion they're strongly trumped by practical concerns, born
out by historical complaints.  Let's please not repeat the same errors; author
usability trumps theoretical consistency here.

(If we just *fixed ES Maps* to not be impossible to subclass safely, this
wouldn't be nearly as much of a concern. Alas, es-discuss keeps shooting me
down.  It's a huge mistake, but what can you do when the spec editors don't

You are receiving this mail because:
You are on the CC list for the bug.
Received on Wednesday, 17 September 2014 19:09:45 UTC

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