[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

no-argument sort

Alex Fenton

12/14/2004 9:57:00 PM

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 }
12 Answers

Jim Menard

12/14/2004 10:10:00 PM

0

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

Mauricio Fernández

12/14/2004 10:37:00 PM

0

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?

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.

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

Alex Fenton

12/14/2004 11:07:00 PM

0

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?

Yukihiro Matsumoto

12/14/2004 11:37:00 PM

0

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.

Florian Gross

12/14/2004 11:47:00 PM

0

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?

Michael Neumann

12/14/2004 11:48:00 PM

0

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

Regards,

Michael

Yukihiro Matsumoto

12/15/2004

0

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.

T. Onoma

12/15/2004 12:18:00 AM

0

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.

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

Thanks,
T.

Florian Gross

12/15/2004 12:20:00 AM

0

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.

T. Onoma

12/15/2004 1:01:00 AM

0

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.

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.