From: Yossef Mendelssohn <ymendel@...>
Date: 2009-06-16T03:17:24+09:00
Subject: Re: each by arity

--00163662e5c6b025d3046c671178
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On Sun, Jun 14, 2009 at 11:22 PM, trans <transfire@gmail.com> wrote:

> On Jun 14, 4:43 pm, Yossef Mendelssohn <ymen...@pobox.com> wrote:
> > And how is that going to happen based on inspecting arity? At least
> > with 1.8.6, Proc.new {|x, y| } and Proc.new {|(x, y)| } both have an
> > arity of 2.
>
> The underlying systems has to see the difference regardless.


This is true. I was just pointing out that it's not arity that stores the
difference, and that makes this at least a little more difficult.


> (Also, I think one could argue that either this arity is wrong, or the
> concept of
> arity needs to be expanded with an added dimension.)


You can argue a lot of things, and I'm sure you want to. Personally, I have
yet to find the Ruby concept of block arity lacking, but then again I don't
try to do anything clever with it.


> > > each_slice is a lot clearer.
> >
> > Yes. Yes, it is.
>
> Slice by arity seems pretty clear to me. Moreover, where is
> #map_slice? It starts to look a lot clearer when we think of adding
> "_slice" to every Enumerable method.


Why is map_slice needed? What's the problem with calling each_slice and then
map on the result? Is it a case of optimization? Are you worried about the
resources you'll be using? If so, it's quite possible to use each_slice to
iterate over one collection while appending results to an array. But maybe
it's not functional enough for you. Or core enough.

Go ahead and call out the Enumerator now.


I have no trouble with requiring 'enumerator' and explicitly using exactly
the methods I want. I'd rather be clear than clever.

-- 
-yossef

--00163662e5c6b025d3046c671178--