Hi --

On Wed, 27 Nov 2002, Jason Persampieri wrote:

> OK... globals = evil... more importantly cryptic code
> = evil.  I can appreciate that.  And I think getting
> rid of the extraneous _with_index methods would clean
> things up a bit.

Heh -- I guess you're not interested in membership in Citizens for MWI
(map_with_indices) :-)


> But I'm still determined to come up with a solution ;)
>
> Can we arbitrarily add a parameter to the block?
> Something like:
>
> ary.collect {|a,b,c,:iteration| ...}
>
> The idea is if there is an argument beginning with
> ':', assign the iteration value/object for this
> particular block to that.

If you want to change the syntax of block variable names, you'll have
to get in line and wait your turn :-)  But the other problem with this
is that you're introducing syntax change, just so you don't have to
type "_with_index".  That's not a good trade-off.

> That way, block are still easily nestable.  As for
> your other comment... is it really necessary to have
> an index associated with each argument?  Shouldn't
> they all be synchronized?

In tinkering with this, the problem I was running into was with nested
arrays.  Let's say you define Enumerable#imap, which does a map
operation but also adds an "iteration" method to each object in the
receiver as it iterates.

  a = [ ["one", "two"], ["three", "four"] ]
  a.imap {|e| puts "we're at #{e.iteration}"}

But now let's say you do:

  a.imap {|e,f| .... }

which assigns the inner array elements to e and f.  Now, somewhere
behind the scenes (in my version), you're adding the #iteration method
to the actual objects being iterated.  But here, the object -- the
inner array -- doesn't actually appear as itself in the block; it's
split across two variables.  So you can't say "e.iteration" or
"f.iteration", because the original [e,f] array (["one","two"]) is the
object that responds to "iteration".


David

-- 
David Alan Black
home: dblack / candle.superlink.net
work: blackdav / shu.edu
Web:  http://pirate.shu.edu/~blackdav