From: Ben Tilly <ben_tilly@...>
Date: 2001-01-10T13:09:55+09:00
Subject: [ruby-talk:8979] Re: Modules and mixins

"Christoph Rippel" <crippel@primenet.com> wrote:
>
> > -----Original Message-----
> > From: Ben Tilly [mailto:ben_tilly@hotmail.com]
> > Sent: Tuesday, January 09, 2001 03:52 AM
> > To: ruby-talk ML
> > Subject: [ruby-talk:8917] Re: Modules and mixins
>...
> > Say no more.  Explicit calculations open up room for all
> > sorts of potential mistakes.
>they are also very inefficient and are either (virtually)
>impossible or absurdly complex if you start adding
>additional ``if clauses'' etc.  ...

While the point is understood, in this case I suspect that
parameter passing overhead is substantially higher.
> > >
>...
> > Not much of a trick.  I just intended to use argument
>if you know it ....

I just made it up, thought it was probably standard?

In fact I was noticing how moving from Perl to Ruby I
was able to avoid some of the explicit argument
assignment, figured I might as well try to remove the
rest...

> > processsing to do what would otherwise be mechanical in
> > my original Perl version.
>...
> > my solution.  I think I like the pattern of this one
> > better, just a tad more direct.  However I would
> > prefer different names:
>On the other hand your solution is more fun and you can
>replace the final ``[]'' with the mandatory ``[6,6,6]''.
>Seriously it is probably a good idea to distribute the
>argument pre-processing (in both solutions) over two
>function calls, lets say  along the lines of

Another advantage to my solution is that easy
variants of it work in a large number of languages.
As long as the basic functional paradign works, that
solution will work.

Also the function you start with could itself have
come from some function that produced a ton of
closures.  I may be mistaken, but I think that if
you tried this with blocks you would lose the
closure from which they came?  (I may be seriously
mistaken here.)

Thus there is a small iota of flexibility in the
functional approach at the cost of a worse interface.

>class Array
>   def  multi_each  # or each_comb, iter_each  ...
>     __e(*self) {|arg| yield arg } unless empty?
>   end
>   private
>   def  __e (arg,*more_args)
>     (more_args.empty?) ?
>        arg.each { |r| yield [r] } :
>        arg.each {|l| __e(*more_args) {|r| yield [l]+ r }}
>   end
>end
>
>[1...3,'a'..'c', ('A'..'D').to_a].multi_each \
>{ |arg|  puts arg.join " " }
>
>[].multi_each \
>{ |arg|  puts "nothing"  }
>
>This is sort of complementary to the proposed ``zip''
>(not that I am suggesting to include this in the Array
>interface).

Isn't Array a rich enough class already? :-)

FWIW the the times I reach for a functional approach
tend to fall under the labels, "callback", and "handler".
(A hash of anonymous functions is a surprisingly
flexible control structure.)

Cheers,
Ben
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com