| |
 |
|
| Computers Forum Index » Computer Languages (Ruby) » RCR enumerable extra into core... |
|
Page 1 of 1 |
|
| Author |
Message |
| Roger Pack... |
Posted: Sun Nov 08, 2009 5:22 am |
|
|
|
Guest
|
|
| Back to top |
|
|
|
| Tor Erik Linnerud... |
Posted: Sun Nov 08, 2009 5:43 am |
|
|
|
Guest
|
|
| Back to top |
|
|
|
| David A. Black... |
Posted: Sun Nov 08, 2009 5:57 am |
|
|
|
Guest
|
Hi --
On Sun, 8 Nov 2009, Roger Pack wrote:
Quote: I'm considering suggesting that the base functionality for the
enumerable-extra gem[1] be submitted into core.
In a nut shell, it's that you can do
list.map :name
as an alternative to
list.map &:name
which is arguably less readable.
Thoughts?
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. It would also mean that map (and maybe other Enumerable
methods) had one argument syntax and all other iterators had another,
since presumably there's no general way to make method(:sym) know when
it's supposed to actually mean method(&:sym). I don't think that's a
useful special case.
(I know there's inject(:method), but note that that's a different
case; inject(:method) is not shorthand for inject(&:method).)
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) |
|
|
| Back to top |
|
|
|
| Gavin Sinclair... |
Posted: Sun Nov 08, 2009 6:00 am |
|
|
|
Guest
|
On Nov 8, 11:57 am, "David A. Black" <dbl... at (no spam) rubypal.com> wrote:
Quote:
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. 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.
--
Gavin Sinclair |
|
|
| Back to top |
|
|
|
| David A. Black... |
Posted: Sun Nov 08, 2009 6:00 am |
|
|
|
Guest
|
On Sun, 8 Nov 2009, David A. Black wrote:
Quote: (I know there's inject(:method), but note that that's a different
case; inject(:method) is not shorthand for inject(&:method).)
I garbled that bit, due to an irb session gone horribly wrong So
forget that sentence. I do have a feeling there's something my brain
is groping toward that differentiates the inject case, but I could be
totally wrong about that.
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) |
|
|
| Back to top |
|
|
|
| David A. Black... |
Posted: Tue Nov 10, 2009 6:17 am |
|
|
|
Guest
|
Hi --
On Tue, 10 Nov 2009, Roger Pack wrote:
Quote:
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.
Quote: 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).
Quote: 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) |
|
|
| Back to top |
|
|
|
| Haoqi Haoqi... |
Posted: Tue Nov 10, 2009 6:17 am |
|
|
|
Guest
|
list.map(:symbol) is just like object.send(:symbol),except the :symbol
for list.
so list.map(:symbol) is good~
--
Posted via http://www.ruby-forum.com/. |
|
|
| Back to top |
|
|
|
| Marnen Laibow-Koser... |
Posted: Tue Nov 10, 2009 6:17 am |
|
|
|
Guest
|
Haoqi Haoqi wrote:
Quote: list.map(:symbol) is just like object.send(:symbol),except the :symbol
for list.
But it isn't. The semantics of the two are completely different. You
can only send a method name, but a naked method name doesn't make any
sense as an argument to map.
Quote: so list.map(:symbol) is good~
Because you don't understand what's going on? No thanks.
Best,
--
Marnen Laibow-Koser
http://www.marnen.org
marnen at (no spam) marnen.org
--
Posted via http://www.ruby-forum.com/. |
|
|
| Back to top |
|
|
|
| Gavin Sinclair... |
Posted: Wed Nov 11, 2009 5:22 am |
|
|
|
Guest
|
Brian Candler wrote:
Quote: one logical conclusion (or extreme viewpoint) is that you could always
return an Enumerator, even for
map { |x| x*x }
I wasn't saying that Ruby does anything like this, and it's a tangent to
the original thrust of map(:foo).
That's a pretty yucky option. I use map all the time, and I expect to
get an array back. Adding to_a everywhere is not cool.
Lazy evaluation is cool, though. But it would need a thorough
reconsideration of the language. And considering that Ruby is doing
pretty well without it...
--
Gavin Sinclair |
|
|
| Back to top |
|
|
|
|
|
All times are GMT
The time now is Sun Nov 22, 2009 12:50 am
|
|