Discuss
  • Array extras and Objects

Array extras and Objects

# Andrea Giammarchi (13 years ago)

Let's say this is an attempt to bring some new, easy to implement, method for the native Object.prototype Specially about forEach, the most used Array.prototype method out there, it's quite clear JS developers would like to have similar method to iterate over objects, as key:value pairs rather than index:value.

Almost every framework/library out there has an "error prone" each(obj, callback) method, able to automagically recognize if the passed obj is an array, an arrayLike, or an object. A classic failing scenario is a function used as object, where the length property won't mean it's an arrayLike entity.

As summary, I wonder if this proposal could make things more explicit, easy to remember, and faster, if implemented natively: gist.github.com/1410420

where more details about the "why" and "how", through examples, are explained in my post: webreflection.blogspot.com/2011/11/array-extras-and-objects.html

The quick version, and all I am asking is an opinion about this, is

obj.forEach(function (value, key, original) { // all true conditions original.hasOwnProperty(key); value === original[key]; original === obj; this === optionalContext; }, optionalContext);

Thanks for any sort of feedback.

Best

# Dmitry Soshnikov (13 years ago)

On 01.12.2011 11:47, Andrea Giammarchi wrote:

Let's say this is an attempt to bring some new, easy to implement, method for the native Object.prototype Specially about forEach, the most used Array.prototype method out there, it's quite clear JS developers would like to have similar method to iterate over objects, as key:value pairs rather than index:value.

Almost every framework/library out there has an "error prone" each(obj, callback) method, able to automagically recognize if the passed obj is an array, an arrayLike, or an object. A classic failing scenario is a function used as object, where the length property won't mean it's an arrayLike entity.

As summary, I wonder if this proposal could make things more explicit, easy to remember, and faster, if implemented natively: gist.github.com/1410420

where more details about the "why" and "how", through examples, are explained in my post: webreflection.blogspot.com/2011/11/array-extras-and-objects.html

The quick version, and all I am asking is an opinion about this, is

obj.forEach(function (value, key, original) { // all true conditions original.hasOwnProperty(key); value === original[key]; original === obj; this === optionalContext; }, optionalContext);

Yep, the topic was raised before (by me in particular) of implementing richer standard libraries for all classes (Array and Object are first on this list; and especially `forEach' for Object instances). On what Allen said that time something like "before proposing many methods for classes, let's understand first where we go w/ classes at all".

Which though doesn't cancel the fact that JS has pure lib for standard library. Of course monkey patching allows to fix this issues ourselves (w/o waiting while the committee start to move in this direction), but of course it's good to have this functionality built-in.

Dmitry.

# Dmitry Soshnikov (13 years ago)

On 01.12.2011 11:51, Dmitry Soshnikov wrote:

On 01.12.2011 11:47, Andrea Giammarchi wrote:

Let's say this is an attempt to bring some new, easy to implement, method for the native Object.prototype Specially about forEach, the most used Array.prototype method out there, it's quite clear JS developers would like to have similar method to iterate over objects, as key:value pairs rather than index:value.

Almost every framework/library out there has an "error prone" each(obj, callback) method, able to automagically recognize if the passed obj is an array, an arrayLike, or an object. A classic failing scenario is a function used as object, where the length property won't mean it's an arrayLike entity.

As summary, I wonder if this proposal could make things more explicit, easy to remember, and faster, if implemented natively: gist.github.com/1410420

where more details about the "why" and "how", through examples, are explained in my post: webreflection.blogspot.com/2011/11/array-extras-and-objects.html

The quick version, and all I am asking is an opinion about this, is

obj.forEach(function (value, key, original) { // all true conditions original.hasOwnProperty(key); value === original[key]; original === obj; this === optionalContext; }, optionalContext);

Yep, the topic was raised before (by me in particular) of implementing richer standard libraries for all classes (Array and Object are first on this list; and especially `forEach' for Object instances). On what Allen said that time something like "before proposing many methods for classes, let's understand first where we go w/ classes at all".

esdiscuss/2011-July/015891 (I slightly rephrase that as I see :))

# gaz Heyes (13 years ago)

On 1 December 2011 07:47, Andrea Giammarchi <andrea.giammarchi at gmail.com>wrote:

Let's say this is an attempt to bring some new, easy to implement, method for the native Object.prototype Specially about forEach, the most used Array.prototype method out there, it's quite clear JS developers would like to have similar method to iterate over objects, as key:value pairs rather than index:value.

You can sorta do this now but it only accepts numeric indexed properties. E.g.

({0:1,1:2,proto:[],length:2}).forEach(alert)

and

[].forEach.apply(({0:1,1:2,length:2}),[alert])

So I agree to be able to do this with any property type would be useful

# Andrea Giammarchi (13 years ago)

you could have showed just arguments ... you don't even need the proto as Array.prototype to use forEach over ArrayLike objects but you got the point, it's not about indexes, its' about objects.

For Dmitry, these are truly simple things to add to current status, and even if classes will be the coolest thing ever I strongly doubt Objects as we know will disappear.

If these will stay, then we'll need a native want to iterate regardless what will be for classes, you know what I mean?

Thanks in both cases for your feedbacks.

br, andrea

# David Bruant (13 years ago)

Le 01/12/2011 08:47, Andrea Giammarchi a écrit :

Let's say this is an attempt to bring some new, easy to implement, method for the native Object.prototype Specially about forEach, the most used Array.prototype method out there,

That's quite an ambitious statement. I use forEach, but I think I use push, concat, every/some, map and reduce quite often as well and I wouldn't be able to tell which I use more often (probably push).

it's quite clear JS developers would like to have similar method to iterate over objects, as key:value pairs rather than index:value.

It seems that iterators [1] could do what you need. In this proposal (so very likely to be in ES.next), you can see this example:

for ([key, val] of items(x)) { alert("x." + key + " = " + val); }

There is even the possibility for you to define your own iterator on your objects.

Almost every framework/library out there has an "error prone" each(obj, callback) method, able to automagically recognize if the passed obj is an array, an arrayLike, or an object. A classic failing scenario is a function used as object, where the length property won't mean it's an arrayLike entity.

If some library authors think that an array is an object with a 'length' property, I think that they should learn JavaScript and that is not a reason to add a language feature.

David

[1] harmony:iterators

# Rick Waldron (13 years ago)

On Dec 1, 2011, at 8:04 AM, David Bruant <bruant.d at gmail.com> wrote:

Le 01/12/2011 08:47, Andrea Giammarchi a écrit :

Let's say this is an attempt to bring some new, easy to implement, method for the native Object.prototype Specially about forEach, the most used Array.prototype method out there, That's quite an ambitious statement. I use forEach, but I think I use push, concat, every/some, map and reduce quite often as well and I wouldn't be able to tell which I use more often (probably push).

it's quite clear JS developers would like to have similar method to iterate over objects, as key:value pairs rather than index:value. It seems that iterators [1] could do what you need. In this proposal (so very likely to be in ES.next), you can see this example:

for ([key, val] of items(x)) { alert("x." + key + " = " + val); }

There is even the possibility for you to define your own iterator on your objects.

Almost every framework/library out there has an "error prone" each(obj, callback) method, able to automagically recognize if the passed obj is an array, an arrayLike, or an object. A classic failing scenario is a function used as object, where the length property won't mean it's an arrayLike entity. If some library authors think that an array is an object with a 'length' property,

The precedent was set by DOM APIs (eg NodeList)

# Andrea Giammarchi (13 years ago)

... iterators not backward compatible ... a failing solution for me for this very simple and common problem :-/

# Brendan Eich (13 years ago)

On Dec 1, 2011, at 8:00 AM, Andrea Giammarchi wrote:

... iterators not backward compatible ... a failing solution for me for this very simple and common problem :-/

What is wrong with the standard combination, which would be the basis for any polyfill (including a polyfill for Object.keys)?

js> o = {p:1,q:2,r:3} ({p:1, q:2, r:3}) js> Object.keys(o).forEach(function (k) {print (k, o[k])})

p 1 q 2 r 3

# Andrea Giammarchi (13 years ago)

nothing wrong, that's basically what I do indeed as Object.prototype.forEach but it would be faster done natively