no-argument sort()

[Alex Fenton]

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 }

 

[Jim Menard]

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

 

[Mauricio Fernández]

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?

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.

 

[Alex Fenton]

The String subclass

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

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

 

[Yukihiro Matsumoto]

In message "Re: no-argument sort()"

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

Performance compromise.

matz.

 

[Florian Gross]

In message "Re: no-argument sort()"

|> 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?

 

[Michael Neumann]

In message "Re: no-argument sort()"

|> 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? ;-)

Regards,

Michael

 

[Yukihiro Matsumoto]

Hi,

In message "Re: no-argument sort()"

|> 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.

 

[trans. (T. Onoma)]

no-argument sort()"
|
| on Wed, 15 Dec 2004 08:12:17 +0900, Alex Fenton
| |> It bypasses #<=> for objects of class String and subclasses
| |
| |Is that considered a bug, a feature or a performance compromise?
|
| Performance compromise.
|
| matz.

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

Thanks,
T.

 

[Florian Gross]

| |> 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.

 

[trans. (T. Onoma)]

| > | |> 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.

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.

 

[Robert Klemme]

In message "Re: no-argument sort()"

|> 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...

Regards

robert

 

[Joel VanderWerf]

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...

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