Hi --

On Thu, 28 Nov 2002, Hal E. Fulton wrote:

> ----- Original Message -----
> From: <dblack / candle.superlink.net>
> To: "ruby-talk ML" <ruby-talk / ruby-lang.org>
> Sent: Wednesday, November 27, 2002 6:50 AM
> Subject: Re: each_with_index & collect_with_index?
>
>
> [snippage]
>
> > 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,
>
> Adding singletons to the iterator variable was
> a path that I went down once... it had some
> drawbacks, e.g., no Fixnums and overhead of
> adding a singleton to *each object*.
>
> Now that you've been playing with this some,
> what are your thoughts on my "super-iterator"
> from a few months back?

Yes, I was reminiscing about that, and realizing that I was
semi-reinventing it :-) But I just can't find the right "home" for an
internal iteration counter.  Extending the object has so many
problems, and the various global techniques are, well, global.

One thing I believe is missing, conceptually speaking, is the ability
on the part of a proc or code block to capture a reference to itself
from inside itself.  If it could, then each block could be extended to
have a counter for itself.  I think.  Maybe.  That's the only avenue I
can think of to go down which doesn't feel like it's stacking too much
info into too little namespace.  Then again, it might not be thread
safe.  But it could report out its counter based on a thread-based
hash....


David

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