Hello --

On Tue, 6 Nov 2001, Alexander Schofield wrote:

> David Alan Black wrote:
> > But you really do get into the problem that Eli Green mentioned, namely
> > that you're then storing all these things rather than iterating over them.
> > That could be very costly.
>
> Yes, but sometimes that is exactly what you were going to do anyways.
> It's not that storing them instead of iterating over them is preferable,
> but sometimes you have no choice.  Given that, a statement like nums =
> list.eachOver57 makes intuitive sense, where eachOver57 is an iterator
> method.

But I don't think eachOver57 would be likely to be an iterator.  I
think it would be likely to *call* an iterator:

  class Array
    def eachOver57
      find_all do |e| e > 57 end
    end
  end

  list = [12,34,56,78,90]
  nums = list.eachOver57 # => [78,90]

So yes, what gets returned is a stored array, but creating that array
involves iterating over another array (in this case, with find_all).

> > Also, what do you mean by "return"?  Methods still need to have a return
> > value.  For example:
> >
> >   def thing
> >     yield 123
> >     return 456
> >   end
> >
> > In the absence of a block, what would happen to that 123?
>
> Well, alot of iterator methods are usually only called for their
> side-effects (with [1,2].each {...} we don't really care what each
> returns).  So the way to approach this would seem to be to have an
> iterator method (which doesn't have to return anything else) return a
> call to yield, which would have to have a different behavior (all the
> things discussed, like the ability to detect when it was called without
> a block, and use a ?default? block instead).  So one example of an
> iterator method where this would work would be:
> def someIterator
> 	yield 1, 2
> 	return yield (3,4)
> end
> but it wouldn't work with:
> def otherIterator
> 	yield 1, 3
> 	return 15
> end
>
> However, many iterator methods already resemble the former.  So the real
> challenge is to change the behavior of yield.  Of course, for this to
> work yield would need to be able to have a default block to fall back on
> which is able to preserve the state of the Array to be returned between
> calls from yield.  This would be a nice feature which I also can't see
> breaking alot of code (not that not breaking code should be a large
> impediment to improvement anyways).

I'm still not getting it.  "yield" means "yield control to a
block/proc".  You seem to be talking about a kind of built-in default
accumulator, which may or may not be useful (not sure yet :-) but
which doesn't seem to me to involve yielding.

For instance: when you say "have an iterator method (which doesn't
have to return anything else) return a call to yield", what I would
want to know is: to what is that yield call yielding control?  And if
nothing -- if this new "yield" isn't yielding -- , then why is it
called "yield"?

(By the way, I'm not as happy as you are about dismissing return
values of iterators, but we can leave that to the side :-)


David

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