util.each should always have the same argument order

[jcemer]

Penso que a gente não deva inverter o comportamento do each.

Quando se tá mexendo em coleções que contém tanto arrays quanto objetos esse comportamento é estranho e confuso.

A sugestão é que a gente implemente todos os each como jQuery ou tire qualquer referência a eles da biblioteca apesar de ser super útil ter um atalho para for (var key in obj) if (_hasOwnProperty.call(obj, key))

[jcemer]

Uma ideia melhor, manter a assinatura

each(function(value, key) { ... })

Tanto para objetos quanto para arrays (ops, array tambem é objeto (: )

[ricardobeat]

voltando tudo. eu inverti só pra ficar igual ao forEach no caso do array. Não curto o value, key pra objeto porque não dá pra usar função com um argumento só (como no forEach), perde acesso à chave, já se tu tiver a chave primeiro consegue pegar o valor de qualquer maneira.

Podemos deixar a mesma ordem key, value pros dois, o cara deveria estar usando forEach mesmo. ou remover o suporte a arrays, era só pra ganhar de graça arrays passados pro removeListener :D

[ricardobeat]

http://jsperf.com/object-looping

[jcemer]

Eu tinha sacado que faz sentido usar valor / chave em array por causa do valor ser mais importante e que talvez isso nao seja tão verdade pra objetos.

Mas em casos extremos como esse https://github.com/jcemer/rye/blob/master/lib/ajax.js#L11 só vou poder usar o util.each se a assinatura for a mesma. Eu não vejo problema usarmos valor / chave em todos os casos que iteramos precisamos dos dois. Fica como método de uso interno em último caso.

Concorda?

[ricardobeat]

Sim, entendi, sugeri key, value pra ambos, já que o propósito principal do each é facilitar loop com objetos, nao arrays. Não queria expor um funcao com os argumentos invertidos.

[jcemer]

Mas dessa maneira não teríamos que inverter Rye.each? Quero dizer, elas teriam comportamentos diferentes. :/

[ricardobeat]

nada a ver o cú com as calças, Rye.each() itera sobre um array e está em
conformidade com o forEach. util.each não deve ser usado pra arrays
(podia indicar na documentação até) pela performance muito pior.

Sent from my iPhone

On 26/12/2012, at 15:36, Jean Carlo Emer notifications@github.com wrote:

Mas dessa maneira não teríamos que inverter Rye.each? Quero dizer, elas
teriam comportamentos diferentes. :/

—
Reply to this email directly or view it on
GitHubhttps://github.com/jcemer/rye/issues/8#issuecomment-11690436.

[jcemer]

Bah, eu não consigo ver isso com tanta clareza. Estamos falando de "orientacao a objetos", o fato de termos [].each e {}.each é pra que o comportamento da callback seja o mesmo.

O que penso é: tira todos os each ou faz com que o discurso deles seja o mesmo.

[jcemer]

Uma implementação de 2006 de forEach para objetos http://dean.edwards.name/weblog/2006/07/enum.

Um texto comparando objetos com arrays associativos http://www.quirksmode.org/js/associative.html.

Eu acho que não podemos colocar em pontos tão diferentes arrays e objetos.

[ricardobeat]

Deixamos value, key então pra ficar consistente. Eu gostaria de ter um
forKeys() mas acho que vai ficar de fora da lib ;)

Sent from my iPhone

On 26/12/2012, at 20:54, Jean Carlo Emer notifications@github.com wrote:

Uma implementação de 2006 de forEach para objetos
http://dean.edwards.name/weblog/2006/07/enum.

Um texto comparando objetos com arrays associativos
http://www.quirksmode.org/js/associative.html.

Eu acho que não podemos colocar em pontos tão diferentes arrays e objetos.

—
Reply to this email directly or view it on
GitHubhttps://github.com/jcemer/rye/issues/8#issuecomment-11696247.

[jcemer]

Podiamos deixar dois: forEach e forKeys e não ter mais nenhum each. Pode ser interessante. Que acha?

[ricardobeat]

Não vale a pena ter a mesma função só com os argumentos invertidos, por isso ficar de fora.

[jcemer]

Confere se está de acordo.