Re: Symbol#===

On Tue, Jun 28, 2011 at 10:04 AM, Robert Dober <[e-mail]>wrote:

> On Tue, Jun 28, 2011 at 2:57 PM, Robert Klemme
> <[e-mail]> wrote:
> > On Sat, Jun 25, 2011 at 9:15 PM, Intransition <[e-mail]>
> wrote:
> <snip>
> Thx for fixing it;)
> still not the biggest fan of it though
> >
> > No, I like it.
> Really, I mean do you like to use it, as do I, or do you like it
> conceptionally? I would much prefer map(:to_s) to map(&:to_s) because
> now it is each's responsibility of what to do with a symbol, and map
> could even intercept. It also gives it much more possibilities as e.g.
> map(:+,42). And other methods than #each could do completely other
> things, especially not allowing symbols to be passed in, imagine e.g.
>
> config(&:hello!)
>
> Loading the responsibility of to_proc to Symbol I dunno, but anyway it
> will be here for ever now....
>
>
I think it is best the way it is. They want a function, you're providing
one. That is pretty straight forward and conceptually elegant (even if it
can get ugly to look at).

This makes it consistent everywhere. If you instead pass that possibility to
#map, you will end up with lots of edge cases where some methods don't
implement it the same and some don't implement it at all and so forth. I
consider these kinds of inconsistencies to be often times harmful, and
nearly always distasteful.

For example: unix command line programs interpreting their flags however
they like thus leading to highly inconsistent interfaces. Every time I use
find, for example, I check `$ cheat find`.


I think your example of map(:+, 42) would be better achieved with more
functional support. Something along these lines:
def f(meth, *args)
  Proc.new do |obj|
    obj.send meth, *args
  end
end
nums = [10, 20, 30]
nums.map(&(f :+, 5)) # => [15, 25, 35]
nums.map(&(f :-, 5)) # => [5, 15, 25]