From: Robert Dober Date: 2009-06-17T19:22:57+09:00 Subject: Re: each by arity On Wed, Jun 17, 2009 at 6:49 AM, trans wrote: > > > On Jun 16, 7:43 pm, Robert Dober wrote: >> On Tue, Jun 16, 2009 at 12:33 PM, trans wrote: >> >> > On Jun 16, 2:10 am, Robert Klemme wrote: >> >> >> Question is whether it is clever to duplicate all methods with another >> >> one that has "_slice" appended to the name.  I personally favor the >> >> approach with Enumerator, e.g. depending on version >> >> > Not clever... facetious. Of course Enumerator is useful, and with 1.9 >> > fairly elegant. But rather, the question is why we must do >> >> >  enum.each_slice(2).map {|a,b| ...} >> >> > when >> >> >  enum.map {|a,b| ...} >> >> > could be made to work. This is especially interesting b/c it seems the >> > underlying implementation stands to be simpler and faster by doing so. >> >> That is intriguing and I am surprised. >> >> However, why should >> >>   enum.map{ |a,b| } >> have the semantics of >>   enum.each_slice( 2 ).... >> and not >>    enum.each_cons( 2 ).... ? >> >> Maybe we need to push the abstraction even higher. Hopefully you >> understand what that sentence means, because I do not, but it felt >> just right to write it. Strange, strange. > > Simply b/c cons is uncommon. We want to iterate over elements once and > only once, where as cons hits on the same elements multiple times. Of > course, I see no reason cons could not look at arity too. Maybe we should map leave alone and use the enumerable approach coll.cons.each{ |a,b| ... coll.slice.each { |a,b|... I like this because I am used to "waiting" in proxy objects for what they are really to be used later, but it might be troubling for others. Do you think it is a good idea to implement it in Facets first and ask for inclusion into the core after having some more feedback from users? > > With this idea, I've been wondering about possibilities for passing > blocks that might have one, two or more block arguments --the arity > unknown to the method processing them, and how that might or might > not  be useful. One obvious issue is that arity > 1 produces Array > elements, whereas arity of 1 would not necessarily. > >> Now I am not so fond of enumerator, because it is really crazy. >> >>   x=%w{a b c d} >>   y = x.enum_for( :rand ) >>   y.each do | a | p a end >> => 0.680141319345242 >> >> Do you agree with me that enum_for should use #public_send instead of #send? > > Oh that's nice. I did not think you could use it for anything but > Enumerable methods. I'm not sure it matters if they are public or not. > It still can be crazy. Yeah as long as it justs sends the symbol we cannot avoid that, but I guess this is the price to pay for having it flexible or maybe not? I am not an expert on Enumerator internals. But I definetely want to enumerate over my custom iterators. > > y = x.enum_for(:to_s) > => # >>> y.each{ |a| a } > => "abcd" >>> y.each{ |a| a+'!' } > => "abcd" >>> y.to_a > => [] > > T. > > Cheers R. -- Toutes les grandes personnes ont d’abord été des enfants, mais peu d’entre elles s’en souviennent. All adults have been children first, but not many remember. [Antoine de Saint-Exupéry]