Feature #7340

'each_with' or 'into' alias for 'each_with_object'

Added by Nathan Broadbent over 1 year ago. Updated over 1 year ago.

[ruby-core:49267]
Status:Open
Priority:Low
Assignee:-
Category:lib
Target version:next minor

Description

Following on from the discussions at #7297 and #7241, it is apparent that a shorter alias for 'eachwithobject' would be much appreciated.

History

#1 Updated by Yukihiro Matsumoto over 1 year ago

I dislike #into because it may or may not put something into the argument.
I am OK with #each_with.

Matz.

#2 Updated by kyo endo over 1 year ago

matz (Yukihiro Matsumoto) wrote:

I dislike #into because it may or may not put something into the argument.
I am OK with #each_with.

Matz.

I would appreciate if you could look at #6687. but #each_with is OK for me :-)

#3 Updated by Rodrigo Rosenfeld Rosas over 1 year ago

The reason I dislike eachwithobject and eachwith is the "each" on them. "each"'s return value isn't meaningful to me. That's why I would prefer "mapto", "map_into" or just "into".

"into" here doesn't mean putting values "into" the array or hash. It means: "turn/map object into a hash/array/whatever". It is not about putting something into the passed object, but about converting the original object (say numbers) into the object being passed as the initial value like a hash or an array.

It is ok to chain operations as a pattern (like the one used by jQuery) so that anarray.each{...}.sort would justify "each" returning the original "anarray", but only to be able to chain operations and not because "each" implies returning anything meaningful.

In that sense, eachwithobject is currently supposed to return some meaningful value. That is why I'd prefer to call it "mapto", "mapinto" or just "into".

numbers.mapinto({}){...} should read "map numbers into a hash where ...". It would be even shorter if we just abbreviated "mapinto" as just "into".

Also, if there is any chance that this wouldn't be an alias to eachwithobject, I'd prefer the block's arguments order to be inverted to be symmetric to "inject".

#4 Updated by Matthew Kerwin over 1 year ago

On 13 November 2012 21:25, rosenfeld (Rodrigo Rosenfeld Rosas) <
rr.rosas@gmail.com> wrote:

Issue #7340 has been updated by rosenfeld (Rodrigo Rosenfeld Rosas).

The reason I dislike eachwithobject and eachwith is the "each" on them.
"each"'s return value isn't meaningful to me. That's why I would prefer
"map
to", "map_into" or just "into".

"into" here doesn't mean putting values "into" the array or hash. It
means: "turn/map object into a hash/array/whatever". It is not about
putting something into the passed object, but about converting the original
object (say numbers) into the object being passed as the initial value like
a hash or an array.

It is ok to chain operations as a pattern (like the one used by jQuery) so
that anarray.each{...}.sort would justify "each" returning the original
"an
array", but only to be able to chain operations and not because "each"
implies returning anything meaningful.

In that sense, eachwithobject is currently supposed to return some
meaningful value. That is why I'd prefer to call it "mapto", "mapinto" or
just "into".

numbers.mapinto({}){...} should read "map numbers into a hash where ...".
It would be even shorter if we just abbreviated "map
into" as just "into".

Also, if there is any chance that this wouldn't be an alias to
eachwithobject, I'd prefer the block's arguments order to be inverted to
be symmetric to "inject".

I believe, given that explanation, that #mapto is a far more appropriate
name than #map
into . . . and suddenly the reservations I had about this
alias start to fade away.

There is a clear semantic distinction between #eachwith, where the focus
is on the action performed in the block, and #map
to, where the focus is on
the object returned from the block. So the question is: is this
alias/method meant to be an analogue for #each, or for #map ?

--
Matthew Kerwin, B.Sc (CompSci) (Hons)
http://matthew.kerwin.net.au/
ABN: 59-013-727-651

"You'll never find a programming language that frees
you from the burden of clarifying your ideas." - xkcd

Also available in: Atom PDF