matz / zetabits.com (Yukihiro Matsumoto) writes:

> |Someone asked about a strange inconsistency in Rubicon, and I didn't
> |know the answer. In light of the recent reverse! thread, I thought I'd 
> |post it here:
> 
> This is very preliminary behavior following
> a-bang-method-returns-nil-if-it-does-not-modify-the-recevier
> principle.  The behavior shall be more thorough in the future.

Although I see the reason for returning nil on methods such as gsub!,
is there really any practical reason for doing so on sort! or
reverse! ? This seems to me to be more of an inconvenience than a help, 
and I'm not sure that any program would have a use for the test.
However, I can see a lot of potential problems with programs that try
to be efficient and sort (or reverse) in place.

   ary.sort!.reverse!.each {...

It works fine 99.999% of the time, but occasionally fails with some
message about some undefined method and nil...


Perhaps we're extending the wrong principle here. Just because _some_
! methods return nil, should all of them?

Regards


Dave



Footnotes: 
 Although adding #sorted? to Enumerable might be useful.