Accessing index inside map

ruby-talk
1

dblack@wobblini wrote:

#> OK, i'll be shooting for the moon here. How about passing a parameter? Is
it
#> then possible to make #each or #map same behavior w #each_with_index or
#> #map_with_index or whatever *_with_index so that the ff works,
#>
#> def each(with_index=true) do... end
#>
#> def map(with_index=true) do ... end
#>
#> and thus, we can do
#>
#> [1,2,3,4,5,6].map(true) {|x,i|[2,5].include?(i) ? x : x*2}

···

#
#I'd hope not to see that. I'm actually hoping that maybe someday all
#the boolean flag methods (like instance_methods(true) etc.) will be
#changed :slight_smile: They've always seemed to me to be the most cryptic thing
#in all of Ruby.
#

Yes, you are correct. But there is some sort of give and take here or
balance if i may say (i think i heard the word balance fr you, sir David)..

How about

[1,2,3,4,5,6].map(WITH_INDEX) {|x,i|[2,5].include?(i) ? x : x*2}
or
[1,2,3,4,5,6].map(with_index=>true) {|x,i|[2,5].include?(i) ? x : x*2}

if we don't pass flags or attribs, wouldn't that make creating additional
methods like

each
each_with_index
map
map_with_index
collect
collect_with_index
...

?

it's with_index es all over..

Also, if we create a with_index method, wouldn't that be invoking another
method just for the index, like

each_with_index.map
or
map.with_index

Wouldn't my algorithm slow down? Does not the chain begs for a single method
-which brings us back to the original question...?

kind regards -botp

#David

2

* "Pea, Botp" <botp@delmonte-phil.com> [2005-07-11 20:12:26 +0900]:

How about

[1,2,3,4,5,6].map(WITH_INDEX) {|x,i|[2,5].include?(i) ? x : x*2}
or
[1,2,3,4,5,6].map(with_index=>true) {|x,i|[2,5].include?(i) ? x : x*2}

How about a more 'rails' like implementation:

  [1,2,3].map(:with_index) { |x,ix| ... }
  [1,2,3].collect(:with_index) { |x,ix| ... }
  [1,2,3].collect!(:with_index) { |x,ix| ... }
  [1,2,3].each(:with_index) { |x,ix| ... }
  [1,2,3].each { |x| ... }

···

--
Jim Freeze

3

Peña, Botp wrote:

[...] wouldn't that make creating additional methods like

each
each_with_index
map
map_with_index
collect
collect_with_index
..

?

it's with_index es all over..

It is. None are required; not even each_with_index.

Also, if we create a with_index method, wouldn't that be invoking another
method just for the index, like

each_with_index.map
or
map.with_index

Wouldn't my algorithm slow down? Does not the chain begs for a single method
-which brings us back to the original question...?

Yes. I'm taking sedatives while it's seriously being considered that
an Array should become an Enumerator in order to use its #with_index method
on an intermediate #map object to produce ... an Array ... instead of the
regular #map method with an optional index.

I would have posted a link to the ruby-core thread, but it was my
first post to a mailing list and my MAIL settings were different

Here's a text version (minor EDITs). I'm sure it'll be relevant to you.

   http://www.d10.karoo.net/ruby/xv/ruby-core-1495.txt

You'll see examples using bang! methods.

(( I'd be fascinated to see map!.with_index or map.with_index!
   produce anything intelligible using require 'enumerator'. ))

kind regards -botp

daz

···

from my NEWS settings, so it's messed up (quoted-printable MIME).

4

Hi --

dblack@wobblini wrote:

#> OK, i'll be shooting for the moon here. How about passing a parameter? Is
it
#> then possible to make #each or #map same behavior w #each_with_index or
#> #map_with_index or whatever *_with_index so that the ff works,
#>
#> def each(with_index=true) do... end
#>
#> def map(with_index=true) do ... end
#>
#> and thus, we can do
#>
#> [1,2,3,4,5,6].map(true) {|x,i|[2,5].include?(i) ? x : x*2}
#
#I'd hope not to see that. I'm actually hoping that maybe someday all
#the boolean flag methods (like instance_methods(true) etc.) will be
#changed :slight_smile: They've always seemed to me to be the most cryptic thing
#in all of Ruby.
#

Yes, you are correct. But there is some sort of give and take here or
balance if i may say (i think i heard the word balance fr you, sir David)..

How about

[1,2,3,4,5,6].map(WITH_INDEX) {|x,i|[2,5].include?(i) ? x : x*2}
or
[1,2,3,4,5,6].map(with_index=>true) {|x,i|[2,5].include?(i) ? x : x*2}

if we don't pass flags or attribs, wouldn't that make creating additional
methods like

each
each_with_index
map
map_with_index
collect
collect_with_index
...

?

it's with_index es all over..

I don't know why, at least not the "..." part. Matz has always
considered each case of a possible new method separately, on its own
merits. (And collect_with_index would presumably be just an alias of
map_with_index :slight_smile: I don't think there has to be some automatic
trigger where lots of other _with_index methods had to come into
existence, unless there were cases where there was a good reason for
them. My main argument in favor of map_with_index is actually not
symmetry with each_with_index, but the fact that so many of us have
had to write that method. I don't have an exact formula, but it's
struck me over the years (as with singleton_class) that there's a case
to be made on those grounds for adding it to Array.

David

···

On Mon, 11 Jul 2005, [iso-8859-1] "Peña, Botp" wrote:

--
David A. Black
dblack@wobblini.net

5

Hi --

Peña, Botp wrote:

[...] wouldn't that make creating additional methods like

each
each_with_index
map
map_with_index
collect
collect_with_index
..

?

it's with_index es all over..

It is. None are required; not even each_with_index.

Also, if we create a with_index method, wouldn't that be invoking another
method just for the index, like

each_with_index.map
or
map.with_index

Wouldn't my algorithm slow down? Does not the chain begs for a single method
-which brings us back to the original question...?

Yes. I'm taking sedatives while it's seriously being considered that
an Array should become an Enumerator in order to use its #with_index method
on an intermediate #map object to produce ... an Array ... instead of the
regular #map method with an optional index.

I don't think that's a correct description of what's being considered.
It's more like: have certain Enumerable instance methods, in the
absence of a block, return an enumerator rather than fail. No array
is "becoming" an Enumerator; rather, a method of Array is returning an
Enumerator.

Mind you, my reaction even after looking at it for a long time is that
it's too "magic" and eliptical. But I don't think it's tangled or
illogical. It's just a big leap, because it means Enumerators would
have core rather than stdlib status, so to speak.

David

···

On Mon, 11 Jul 2005, daz wrote:

--
David A. Black
dblack@wobblini.net

6

Ugh. My impression has always been that they couldn't make up their minds, or, didn't think hard enough about picking good names the first time around.

···

On 11 Jul 2005, at 05:27, Jim Freeze wrote:

How about a more 'rails' like implementation:

  [1,2,3].map(:with_index) { |x,ix| ... }
  [1,2,3].collect(:with_index) { |x,ix| ... }
  [1,2,3].collect!(:with_index) { |x,ix| ... }
  [1,2,3].each(:with_index) { |x,ix| ... }
  [1,2,3].each { |x| ... }

--
Eric Hodel - drbrain@segment7.net - http://segment7.net
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04