From: "David A. Black" Date: 2009-11-10T12:41:12+09:00 Subject: Re: RCR enumerable extra into core Hi -- On Tue, 10 Nov 2009, Roger Pack wrote: > >>> which is arguably less readable. >>> Thoughts? >> >> 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. > > Hmm. I suppose I'm of a slightly different opinion--to me > list.map &:symbol > > is less clear than > list.map(:symbol) I don't think that &:symbol is inherently clear, but once you know the rule, then it's just an example of the rule. > If we were required to write > list.map &:symbol.to_proc > > then I would be more easily convinced that list.map(:symbol) is too > implicit. So for me it's implicit already. Part of the problem I think is that map(:symbol) wouldn't really be an abbreviation of map(&:symbol) (which would presumably still work); it would be a new semantics for map, namely that map would now take an argument, but it would look a lot like shorthand for &:symbol. In a way I wish they were more different, so that they wouldn't have to be explained in terms of each other (which I guarantee is how they'll be seen). > I'm not too worried about the run time slowdown...so many methods are > already special cased...it doesn't seem to be a too large concern to the > core guys... Or, looking at it the other way, maybe there are so many special cases that we've reached the quota :-) That's always the flip-side of the precedent reasoning. 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)