--1926193751-568418052-12576911716857
Content-Type: MULTIPART/MIXED; BOUNDARY="1926193751-568418052-1257691171=:26857"

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--1926193751-568418052-12576911716857
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT

Hi --

On Sun, 8 Nov 2009, Gavin Sinclair wrote:

> On Nov 8, 11:57 ¨Âí¬ ¢Äáöéä Á® Âìáãë¢ ¼äâì®®®Àòõâùðáì®ãïí¾ ÷òïôåº
>>
>> I'm very much in sympathy with the position that &:name is ugly. It's
>> always struck me as uncharacteristically line-noise-ish for Ruby
>> (though I also understand the motivation for it). I have trouble
>> talking myself into using it.
>>
>> At the same time, the merit of &:name over :name is that &:name does
>> tell you what's going on, once you know that the & in front of any
>> object (symbol or otherwise) in last-argument position means that the
>> object will be converted to a Proc and play the block role.
>>
>> Having :name magically understood as &:name is, for my taste, too much
>> invisible ink. [...]
>
> I think                          list.map :name
> is clearly to be understood as   list.map { |x| x.send(:name) }
> not as an abbreviation for       list.map &:name
> which I agree is extraordinarily ugly.
>
> I think (don't quote me) allowing #map to take a symbol was debated
> and rejected a long time ago.

It was: http://oldrcrs.rubypal.com/rejected.html#rcr50. Needless to
say that doesn't contractually bind Matz to any eternal decision :-)

There's no doubt it looks better than &:sym. My problem with it is
that it adds a special case (or a small subclass of special cases). I
don't think it would be a disaster, but I always dislike things where
it feels like it has to be accounted for sort of inside out (there's
the general case of &object, the common case of &:sym, and now a kind
of escape from &:sym via :sym).

Mind you, I really don't think it would be a calamity, just a little
hard to account for in terms of what's around it.

> I'd like to see it implemented in core, as it's a shortcut for a
> common idiom, reads nicely and is unambiguous.  I don't know when
> list.inject(:+) started working, but it's a good thing!
>
> One thing occurred to me, though.  Using "send" in the implementation
> would allow access to private methods.  A check would need to be made
> before pulling the trigger.

You could use public_send.


David

-- 
The          Ruby training with D. Black, G. Brown, J.McAnally
Compleat     Jan 22-23, 2010, Tampa, FL
Rubyist      http://www.thecompleatrubyist.com

David A. Black/Ruby Power and Light, LLC (http://www.rubypal.com)
--1926193751-568418052-12576911716857--
--1926193751-568418052-12576911716857--