[#6363] Re: rescue clause affecting IO loop behavior — ts <decoux@...>

>>>>> "D" == David Alan Black <dblack@candle.superlink.net> writes:

17 messages 2000/11/14
[#6367] Re: rescue clause affecting IO loop behavior — David Alan Black <dblack@...> 2000/11/14

Hello again --

[#6582] best way to interleaf arrays? — David Alan Black <dblack@...>

Hello --

15 messages 2000/11/26

[#6646] RE: Array Intersect (&) question — Aleksi Niemel<aleksi.niemela@...>

Ross asked something about widely known and largely ignored language (on

23 messages 2000/11/29
[#6652] RE: Array Intersect (&) question — rpmohn@... (Ross Mohn) 2000/11/29

aleksi.niemela@cinnober.com (Aleksi Niemel) wrote in

[#6723] Re: Array Intersect (&) question — Mathieu Bouchard <matju@...> 2000/12/01

> >Use a hash. Here's code to do both and more. It assumes that

[#6656] printing/accessing arrays and hashes — raja@... (Raja S.)

I'm coming to Ruby with a Python & Common Lisp background.

24 messages 2000/11/30

[ruby-talk:6616] Re: Question on sort!

From: Dave Thomas <Dave@...>
Date: 2000-11-29 05:06:31 UTC
List: ruby-talk #6616
Mathieu Bouchard <matju@cam.org> writes:

> > The latter can be avoided if one follows the no-bang-method-chain
> > rule.  But I don't force you to agree with me (yet ;-).
> 
> If a justification is required, i'd say that the no-bang-method-chain rule
> follows the if-it's-not-necessary-to-return-a-value-it-is-necessary-not-to
> rule. 
> 
> In particular, method chains rely on all the relevant methods to follow
> some specific meta-protocol about return values. The feature of being able
> to chain messages is thus implemented in hundreds and thousands of places,
> which most blatantly violates the DRY principle. The most exploded case of
> non-modularity.

It what way is it different from the various File and IO class methods
all guaranteeing to return a File or IO object? I don't see the DRY
violation.

Take #sort and #sort!  Array#sort returns a new sorted array, leaving
the original untouched.  Array#sort! sorts the original in place.

For consistency, I'd assume they'd both return a reference to the
sorted array, so that I could replace

    ary.sort.reverse

with

    ary.sort!.reverse

That seems reasonable.

Now of course I'd be wrong. Instead, the ! variant sometimes returns
nil: in particular it returns nil when sorting an array of size 0 or
1.

So does #reverse.

So that's two non-intuitive implementations that both do the same
thing. If there's a duplication of imposed behavior, I'd say it's in
the current system.

It comes down to convenience. How often do you care is an array was
modified by a sort? Ever? It would be more efficient to write
Enumerable#sorted? to check, than to sort and see if it
changed. Contrast that with the number of times it's convenient to
chain another method to a sort (I do it all the time). It's
unfortunate that a rarely used side-effect means that I can't sort in
place reliably under these circumstances.


gsub! and sub! give information that's fairly expensive to determine
any other way when they return nil. reverse! and sort! don't.

I'd vote for an end to the convention.


Regards

Dave

In This Thread