Feature #1084: request for: Array#sort_by!

• Status: Closed
• Assignee: matz (Yukihiro Matsumoto)
• Target version: -

[radarek (Radosław Bułat)]

=begin
$ ruby1.9.1 -e "p Array.instance_methods.grep /sort/"
[:sort, :sort!, :sort_by]

sort and sort! override it's version from Enumerable and sort_by is directly from Enumerable, but for symmetry and consistency it would be nice to have destructive sort_by! for Array.

For example:
a = [1,2,3]
a.sort_by! {|e| -e }
p a #=> [3, 2, 1]
=end

[matz (Yukihiro Matsumoto)]

=begin
Hi,

In message "Re: [ruby-core:21709] [Feature #1084] request for: Array#sort_by!"
on Sun, 1 Feb 2009 11:11:26 +0900, Radosław Bułat [e-mail] writes:

|sort and sort! override it's version from Enumerable and sort_by is directly from Enumerable, but for symmetry and consistency it would be nice to have destructive sort_by! for Array.

Despite how you expect, sort_by! is not faster than sort_by at all.
In fact, it would use sort_by internal then replace the receiver. Do
you still want the "dangerous" version?

						matz.

=end

[ko1 (Koichi Sasada)]

• Assignee set to matz (Yukihiro Matsumoto)

=begin

=end

[matz (Yukihiro Matsumoto)]

=begin
Hi,

In message "Re: [ruby-core:21729] Re: [Feature #1084] request for: Array#sort_by!"
on Mon, 2 Feb 2009 12:59:10 +0900, James Gray [e-mail] writes:

|> Despite how you expect, sort_by! is not faster than sort_by at all.
|> In fact, it would use sort_by internal then replace the receiver. Do
|> you still want the "dangerous" version?
|
|I do. :) I know I've typed this line a million times:
|
| a = a.sort_by { … }

OK, OK. I will add (sometime in the future).

						matz.

=end

[murphy (Kornelius Kalnbach)]

=begin
Yukihiro Matsumoto wrote:

Despite how you expect, sort_by! is not faster than sort_by at all.
In fact, it would use sort_by internal then replace the receiver.
I don't expect bang methods to be generally faster, so this wouldn't
come as a surprise. Missing sort_by! has bitten me a lot of times.

[murphy]

=end

[matz (Yukihiro Matsumoto)]

• Status changed from Open to Closed
• % Done changed from 0 to 100

=begin
Applied in changeset r21967.
=end

[rue (Eero Saynatkari)]

=begin
Excerpts from Henri Suur-Inkeroinen's message of Mon Feb 02 12:46:52 +0200 2009:

Issue #1084 has been updated by Yukihiro Matsumoto.

Status changed from Open to Closed
% Done changed from 0 to 100

Applied in changeset r21967.

This seems to break expectations for Enumerable, since the
method cannot be reasonably supported there (and #sort_by
is still defined in Enumerable, as I understand it.) If it
is to remain, I think this should be specifically noted in
the documentation. Additionally, static as the Enumerable
inclusion may be, definining a method that depends on a
mixin seems a bit awkward: perhaps Array should define its
own #sort_by?

Eero

--
Magic is insufficiently advanced technology.

=end

[murphy (Kornelius Kalnbach)]

=begin
Eero Saynatkari wrote:

This seems to break expectations for Enumerable, since the
method cannot be reasonably supported there (and #sort_by
is still defined in Enumerable, as I understand it.) If it
is to remain, I think this should be specifically noted in
the documentation. Additionally, static as the Enumerable
inclusion may be, definining a method that depends on a
mixin seems a bit awkward: perhaps Array should define its
own #sort_by?
matz only added Array#sort_by!.

[murphy]

=end

[murphy (Kornelius Kalnbach)]

=begin
Now the documentation seems a bit confusing:

enum.sort_by! {| obj | block } -> array

Shouldn't it be "array" instead of "enum"?
=end

[rue (Eero Saynatkari)]

=begin
Excerpts from Kornelius Kalnbach's message of Mon Feb 02 13:32:33 +0200 2009:

Eero Saynatkari wrote:

This seems to break expectations for Enumerable, since the
method cannot be reasonably supported there (and #sort_by
is still defined in Enumerable, as I understand it.) If it
is to remain, I think this should be specifically noted in
the documentation. Additionally, static as the Enumerable
inclusion may be, definining a method that depends on a
mixin seems a bit awkward: perhaps Array should define its
own #sort_by?

matz only added Array#sort_by!.

Exactly why I am asking :)

Eero

--
Magic is insufficiently advanced technology.

=end

[radarek (Radosław Bułat)]

=begin
On Mon, Feb 2, 2009 at 3:30 PM, Florian Frank [e-mail] wrote:

I already asked in ruby-core:21318 and didn't get a reply, but what about
Hash#sort and Hash#sort_by or even the !-methods? With insertion-ordered hashes
returning hashes instead of arrays from these methods would now be semantically
useful.

On the one hand it would be nice to have these methods, on the other
hand it would mean that Hash isn't anymore just simple, plain Hash
(because the can be sorted and who knows what else will in the
future). My pragmatic approach tells me that it's not as bad idea to
have it. Without it if someone want to change order of keys he can do
this by:

h = {"b" => "bar", "a" => "foo"}
h = Hash[*h.sort.flatten]
p h

--
Pozdrawiam

Radosław Bułat
http://radarek.jogger.pl - mój blog

=end

[matz (Yukihiro Matsumoto)]

=begin
Hi,

In message "Re: [ruby-core:21752] Re: Feature #1084 request for: Array#sort_by!"
on Mon, 2 Feb 2009 23:30:47 +0900, "Florian Frank" [e-mail] writes:

|I already asked in ruby-core:21318 and didn't get a reply, but what about
|Hash#sort and Hash#sort_by or even the !-methods? With insertion-ordered hashes
|returning hashes instead of arrays from these methods would now be semantically
|useful.

Although I now recognize the ordered hash as 1.9 spec, I still
hesitate to add sorting method that returns "sorted" hash to the Hash
class.

						matz.

=end

[murphy (Kornelius Kalnbach)]

=begin
Yukihiro Matsumoto wrote:

Although I now recognize the ordered hash as 1.9 spec, I still
hesitate to add sorting method that returns "sorted" hash to the Hash
class.
I think I see your point. I always disliked Hash methods returning
arrays, but maybe Hash#select returning a Hash (new in 1.9) is enough
for now.

[murphy]

=end