Discuss
  • Object iteration order

Object iteration order

# Anne van Kesteren (13 years ago)

In "DOM-land" we're designing new APIs that take objects as arguments. Unless objects meet the criteria in esdiscuss/2010-December/012469 invocation of the API method might result in implementation-specific behavior. See also www.w3.org/Bugs/Public/show_bug.cgi?id=20158

Given the convenience of being able to do something like

element.on({click: callback1, resize: callback2})

we're probably going to run with it, but I thought I'd give a heads up. Maybe someone here has a better idea or maybe iteration order will finally be settled on? :-)

# Andrea Giammarchi (13 years ago)

why is iteration order important here? the event notification order is where mousedown will always be called before click, am I missing something? Anyway, this is same discussion we are having in another thread where concerns are:

  1. where is the bubbling/capturing flag ?
  2. is that object.handleEvent ready ?
  3. will be event.off() the counter part ?

Last, from my POV, what is wrong with this suggestion ?

Element.prototype.on = function on(type, handler, capture) { // either this.addEventListener(type, handler, !!capture); // or ... for(var i = 0, c = !!capture, t = [].concat(type), h = [].concat(handler); i < t.length; i++ ) this.addEventListener(t[i], i in h ? h[i] : handler, c);

return this; };

You have granted order too ...

element.on(["click", "resize"], [callback1, calback2]);

or

element.on(["click", "resize"], sameHandler);

or

element .on("click", cb1) .on("resize", cb2) ;

br

# Anne van Kesteren (13 years ago)

On Mon, Jan 7, 2013 at 8:12 PM, Andrea Giammarchi <andrea.giammarchi at gmail.com> wrote:

why is iteration order important here? the event notification order is where mousedown will always be called before click, am I missing something?

The event stuff is a distraction and was merely to illustrate. See www.w3.org/Bugs/Public/show_bug.cgi?id=20158#c1 For the APIs we define in "DOM-land" we aim to have them fully deterministic even when developers do strange things.

# François REMY (13 years ago)

Just to return back on the initial question:

The event stuff is a distraction and was merely to illustrate. See www.w3.org/Bugs/Public/show_bug.cgi?id=20158#c1 For the APIs we define in "DOM-land" we aim to have them fully deterministic even when developers do strange things.

Why not order the keys alphabetically when you use them in a DOM API?

Alphabetical ordering don't make sense on ES objects because of the prototype inheritance and because it would force to transform an enumerator into a list to perform the ordering, but maybe it does in the case of the DOM when it use an ECMAScript object as a dictionary?

# Anne van Kesteren (13 years ago)

On Thu, Jan 10, 2013 at 12:47 PM, François REMY <francois.remy.dev at outlook.com> wrote:

Why not order the keys alphabetically when you use them in a DOM API?

We could, however if iteration order is eventually defined it would be kind of annoying if we sorted things.

# François REMY (13 years ago)

We could, however if iteration order is eventually defined it would be kind of annoying if we sorted things.

Even if iteration order is going to be defined in some way, I doubt it will be intuitive in any way. But I could be wrong, this is just a personal belief.

# Anne van Kesteren (13 years ago)

On Thu, Jan 10, 2013 at 1:22 PM, François REMY <francois.remy.dev at outlook.com> wrote:

Even if iteration order is going to be defined in some way, I doubt it will be intuitive in any way. But I could be wrong, this is just a personal belief.

Based on what? The iteration order of keys that are strings as pointed in OP is both consistent and predictable across implementations of object literals.