No-argument sort()

ruby-talk
1

Hi

I tried the code below- I thought

[a, b].sort

was always the same as

[a, b].sort { | x, y | x <=> y }

and don't understand why it's not in this case. The String subclass method doesn't seem to get called in the no-arg version?

Thanks
alex

···

---
class Fragment < String
   def <=>(other)
     p "Called subclassed method"
     = super
   end
end

a = Fragment.new('abc')
x = Fragment.new('xyz')

p a < x
p x <= a
p [x, a].sort
p [x, a].sort { | i, j | i <=> j }

2

Alex Fenton wrote:

Hi

I tried the code below- I thought

[a, b].sort

was always the same as

[a, b].sort { | x, y | x <=> y }

[a, b] != ["a", "b"]

a and b are variables that can hold strings or anything. They are not strings themselves. If

  a = 'zebra'
  b = 'aardvark'

then [a,b].sort => ["aardvark", "zebra"]

Jim

···

--
Jim Menard, jimm@io.com, http://www.io.com/~jimm

3

static int
sort_2(ap, bp, data)
    VALUE *ap, *bp;
    struct ary_sort_data *data;
{

...

    if (TYPE(a) == T_STRING && TYPE(b) == T_STRING) {
        return rb_str_cmp(a, b);
    }

It bypasses #<=> for objects of class String and subclasses.

···

On Wed, Dec 15, 2004 at 07:02:16AM +0900, Alex Fenton wrote:

Hi

I tried the code below- I thought

[a, b].sort

was always the same as

[a, b].sort { | x, y | x <=> y }

and don't understand why it's not in this case. The String subclass
method doesn't seem to get called in the no-arg version?

--
Hassle-free packages for Ruby?
RPA is available from http://www.rubyarchive.org/

4

Mauricio Fernández wrote:

The String subclass

method doesn't seem to get called in the no-arg version?

<source snip>

It bypasses #<=> for objects of class String and subclasses

Is that considered a bug, a feature or a performance compromise?

5

Performance compromise.

              matz.

···

In message "Re: no-argument sort()" on Wed, 15 Dec 2004 08:12:17 +0900, Alex Fenton <alex@deleteme.pressure.to> writes:

It bypasses #<=> for objects of class String and subclasses

Is that considered a bug, a feature or a performance compromise?

6

Yukihiro Matsumoto wrote:

···

In message "Re: no-argument sort()" > on Wed, 15 Dec 2004 08:12:17 +0900, Alex Fenton <alex@deleteme.pressure.to> writes:

>> It bypasses #<=> for objects of class String and subclasses
>Is that considered a bug, a feature or a performance compromise?
Performance compromise.

Is it considered a bug that it is not yet documented?

7

Yukihiro Matsumoto wrote:

···

In message "Re: no-argument sort()" > on Wed, 15 Dec 2004 08:12:17 +0900, Alex Fenton <alex@deleteme.pressure.to> writes:

>> It bypasses #<=> for objects of class String and subclasses
>
>Is that considered a bug, a feature or a performance compromise?

Performance compromise.

Can we document this in enum.c and/or array.c, where this applies? Any volonteers? :wink:

Regards,

   Michael

8

Sorry, how does that provide better performance? Simply b/c it can't be
overridden?

Thanks,
T.

···

On Tuesday 14 December 2004 06:36 pm, Yukihiro Matsumoto wrote:

In message "Re: no-argument sort()" > > on Wed, 15 Dec 2004 08:12:17 +0900, Alex Fenton <alex@deleteme.pressure.to> writes:
>> It bypasses #<=> for objects of class String and subclasses
>
>Is that considered a bug, a feature or a performance compromise?

Performance compromise.

       matz.

9

"Yukihiro Matsumoto" <matz@ruby-lang.org> schrieb im Newsbeitrag
news:1103067392.286620.29016.nullmailer@x31.priv.netlab.jp...

>> It bypasses #<=> for objects of class String and subclasses
>
>Is that considered a bug, a feature or a performance compromise?

Performance compromise.

Would it make sense to restrict this optimization to String instances
(i.e. not instance of subclasses of String). While it is not very often
that one does subclass String, it can lead to quite some surprise if one
does and <=> is not used...

Btw, I'm a bit surprised that

    if (TYPE(a) == T_STRING && TYPE(b) == T_STRING) {
        return rb_str_cmp(a, b);
    }

does indeed cover subclasses as well. I guess, I'll have to dig into the
source for further education... :slight_smile:

Regards

    robert

···

In message "Re: no-argument sort()" > on Wed, 15 Dec 2004 08:12:17 +0900, Alex Fenton <alex@deleteme.pressure.to> writes:

10

Hi,

···

In message "Re: no-argument sort()" on Wed, 15 Dec 2004 08:47:16 +0900, Florian Gross <flgr@ccan.de> writes:

Performance compromise.

Is it considered a bug that it is not yet documented?

I don't call it a bug. Documentation volunteers are welcome.

              matz.

11

trans. (T. Onoma) wrote:

> >> It bypasses #<=> for objects of class String and subclasses
Sorry, how does that provide better performance? Simply b/c it can't be overridden?

It does not need to go through method lookup and so on.

12

Robert Klemme wrote:

Btw, I'm a bit surprised that

    if (TYPE(a) == T_STRING && TYPE(b) == T_STRING) {
        return rb_str_cmp(a, b);
    }

does indeed cover subclasses as well. I guess, I'll have to dig into the
source for further education... :slight_smile:

IIRC, subclasses of builtin types keep the same basic structure in memory, including the TYPE field.

13

I see. Thanks. If I may then, perhaps there is prudence in having Ruby support
documented non-overridable methods --at least in core. This would bring such
"creatures" out of the shadows of exception into formal, documented
acceptance. For instance, in the current case, Ruby could define #quicksort
(or some such name) to bypass <=> and be non-overridable, while #sort itself
could still use the reusable, albeit slower behavior. This would provided the
best of both alternatives.

T.

···

On Tuesday 14 December 2004 07:22 pm, Florian Gross wrote:

trans. (T. Onoma) wrote:
> > >> It bypasses #<=> for objects of class String and subclasses
>
> Sorry, how does that provide better performance? Simply b/c it can't be
> overridden?

It does not need to go through method lookup and so on.