Re: String not enumerable, what about IO? (was Re: Symbol < String in Ruby > 1.8)

On 10/19/06, [e-mail] <[e-mail]> wrote:
> each still feels like an odd way to ask for an Enumerator.  I'd expect
> to call a method with "enum" in the name.  The automatic Enumerator
> seems to me to be a kind of "magic dot" technique -- not that there's
> anything technically obscure about it (it's clear how it returns the
> Enumerator), but it takes away the ability to parse the code
> left-to-right based on the actual meanings and semantics of the method
> names.

I disagree. I think if you are OK with the idea of functions/methods
being objects just like any other, there's nothing obscure about it at
all, the parsing is quite straightforward.

f = [1, 2, 3].each is simply assigning a value to f; the value happens
to be a piece of code which has some internal state and which will
return each value from the array in turn.

The conceptual problem comes from the fact that Ruby doesn't use the
same syntax for binding code to names as it uses for binding data to
names. If instead of

def f
 ...
end

we were used to writing

f = {||
 ...
}

then you might not find .each so odd.

For example, in Scheme the syntax for binding names to data is the
same as the syntax for binding names to code.

> Even the condition "without a block" is not meaningful, in this sense.
> Absence of block can be used as a flag to trigger this new behavior --
> but there's nothing about the absence of a block that really *means*
> that we're in an Enumerator context.

So if I interpret you correctly, the thing you don't like is that
.each has two conceptually very different behaviors, depending on
whether you give it a code block? i.e. without a code block it returns
a function, with a code block it passes values to the code block.

I can kinda see that. But I think .each returning a function is the
sensible one, and it's the other usage that's the confusing one. I'd
probably have called it something like .with_each


mathew
-- 
<URL:http://www.pobox.com/~meta/>