[#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:6644] Re: Question on sort!

From: Hugh Sasse Staff Elec Eng <hgs@...>
Date: 2000-11-29 17:26:59 UTC
List: ruby-talk #6644
On Wed, 29 Nov 2000, Dave Thomas wrote:

> 
> gsub! and sub! give information that's fairly expensive to determine

But we could introduce sub? -- takes same args as sub! but doesn't change
anything, returns true if sub would change anything, false otherwise...
This would be less expensive than making the changes in a copy [it would
not make the copy or the changes], since as soon as one change was found
the thing could stop.  Similarly for sort?, gsub?, reverse?, rather than
checking afterwards....
   
> any other way when they return nil. reverse! and sort! don't.
> 
> I'd vote for an end to the convention.
> 

Yes.  Sometimes it's worth breaking old code.  Not very
often though! 

I think if a function needs to return a status and
the receiver, then it should return an array, so you
can at least do

foo.sort![0].uniq!

But this is much less elegant than having "will this be
changed?" operators.   ISTR being taught that functions
that have side-effects are generally a bad thing, so 
I would see the removal of this as a step forwards.

It is about the only thing I don't like about Ruby.

If I see this 'nil sometimes' thing as a flaw, then it is an
understandable, human, one; and I intend no disrespect to Matz in putting
my point forward strongly.

> 
> Regards
> 
> Dave
> 
> 
	Thank you,
	Hugh



In This Thread