there is one thing concerning enumerations I really would like to file a CR
about. But I guess it is necessary to open my ears and listen to your POVs
before doing so. I believe that similar things are already done in lots of
extension libraries like e.g. facet.
The most concerning thing is that there will probably be no consensus about
the magic dot notation, I know this has been discussed before.
Here we go
Potential RCR, opinions wanted
···
==============================
The following is a very common pattern.
an_enum.map{ |ele| ele.a_method }
I believe that it is sufficiently common to be generalized.
There are two idioms I would like to see
an_enum.apply_to_all :a_method
and
an_enum.apply_to_all.a_method
the mutating version should also be available
an_enum.apply_to_all! :a_method
and
an_enum.apply_to_all!.a_method
Still feels like the good old "map" and acts like it...
Here's my naive implementation, that produced the result above:
class Array
alias :old_map :map
def map(arg = nil, &block)
if block
old_map &block
elsif ! arg.nil?
if arg.is_a?(Symbol)
old_map {|x| x.send(arg)}
else
raise ArgumentError, "Don't know how to handle #{arg.class} arguments"
end
else
raise ArgumentError, "No parameter and no block given!"
end
end
end
>>> sender: "Robert Dober" date: "Fri, Jan 12, 2007 at 06:56:08PM +0900"
<<<EOQ
> [..]
>
> The following is a very common pattern.
>
> an_enum.map{ |ele| ele.a_method }
>
> I believe that it is sufficiently common to be generalized.
>
> There are two idioms I would like to see
>
> an_enum.apply_to_all :a_method
Ok, I'm still a newbie, but why not extend map instead of introducing a
new method? As in:
Sure a possibility, I personally like it - even with the magic dot notation
(map.capitalize is also a possibility)
if I recall correctly the map extension idea was rather badly seen the last
time, so I did not think about it anymore.
Thank you for the input.
On 1/12/07, Alexandru E. Ungur <alexandru@globalterrasoft.ro> wrote:
"Kiwi"]
Still feels like the good old "map" and acts like it...
Here's my naive implementation, that produced the result above:
class Array
alias :old_map :map
def map(arg = nil, &block)
if block
old_map &block
elsif ! arg.nil?
if arg.is_a?(Symbol)
old_map {|x| x.send(arg)}
else
raise ArgumentError, "Don't know how to handle #{arg.class}
arguments"
end
else
raise ArgumentError, "No parameter and no block given!"
end
end
end
All the best,
Alex
Robert
--
"The best way to predict the future is to invent it."
- Alan Kay
* the suggestion of map(&:meth)
* using "apply" instead of "map" as the name
* rejection by Matz
The reason for rejection was: "It's too functional so that I'm afraid
it would not work well with OO nature of Ruby. Maybe it's matter of
notation."
Ruby 1.9 has the map(&:meth) notation. I'm not its biggest fan
(mostly on aesthetic/visual grounds), but it has the advantage of
being more generalized. & invokes to_proc on its operand; and to_proc
for symbols is defined as:
lambda {|e| e.send(self) }
There's a lot you have to "just know" to grasp what map(&:meth) is
doing, but basically it does this same thing of distributing a
symbolically-identified method across an enumerable.
I knew about the &: kludge - I really hate it - but I did not know about the
rejected RCR.
That's why I asked
ty for your time I will not file a RCR of course
Concerning the old RCRs that are not part of the new site (there are only
two RCR if I am not mistaken) is there any way to put them?
Can I help?
Cheers
Robert
···
On 1/12/07, dblack@wobblini.net <dblack@wobblini.net> wrote:
Hi --
On Fri, 12 Jan 2007, Alexandru E. Ungur wrote:
>>>> sender: "Robert Dober" date: "Fri, Jan 12, 2007 at 06:56:08PM +0900"
<<<EOQ
>> [..]
>>
>> The following is a very common pattern.
>>
>> an_enum.map{ |ele| ele.a_method }
>>
>> I believe that it is sufficiently common to be generalized.
>>
>> There are two idioms I would like to see
>>
>> an_enum.apply_to_all :a_method
>
> Ok, I'm still a newbie, but why not extend map instead of introducing a
> new method? As in:
>
> %w[apples oranges kiwi].map :capitalize # => ["Apples", "Oranges",
"Kiwi"]
>
> Still feels like the good old "map" and acts like it...
* the suggestion of map(&:meth)
* using "apply" instead of "map" as the name
* rejection by Matz
The reason for rejection was: "It's too functional so that I'm afraid
it would not work well with OO nature of Ruby. Maybe it's matter of
notation."
Ruby 1.9 has the map(&:meth) notation. I'm not its biggest fan
(mostly on aesthetic/visual grounds), but it has the advantage of
being more generalized. & invokes to_proc on its operand; and to_proc
for symbols is defined as:
lambda {|e| e.send(self) }
There's a lot you have to "just know" to grasp what map(&:meth) is
doing, but basically it does this same thing of distributing a
symbolically-identified method across an enumerable.
Concerning the old RCRs that are not part of the new site (there are only
two RCR if I am not mistaken) is there any way to put them?
Can I help?
You can look at them for reference, but for 2.0 development Matz has
asked that RCRs be resubmitted individually based on the new version
of the site and the process.
