Feature #1084: request for: Array#sort_by!

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.

• Assignee set to matz (Yukihiro Matsumoto)

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.

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]

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

Applied in changeset r21967.

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.

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]

Now the documentation seems a bit confusing:

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

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

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.

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

Hi,

In message "Re: [ruby-core:21752] Re: [Feature #1084](Closed) 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.

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]