From: Robert Klemme Date: 2005-05-09T14:59:22+09:00 Subject: Re: Introducing Features of other Languages (was: Re: object reference handle (like perl's reference to scalar)) "Dave Burt" schrieb im Newsbeitrag news:r%yfe.7162$31.4588@news-server.bigpond.net.au... > "Robert Klemme" said: >> >> "Dave Burt" schrieb: >>> [Multiple returns are] often quite disobvious, and I'm sure there are >>> cases where it would seem more obvious to modify an argument "in-place", >>> even though "that's not possible in Ruby". >> >> Personally I prefer to not have in place modification. If you view a >> method as some kind of (mathematical) function, then there's an input and >> an output. Returning values via arguments (= input) feels a bit awkward >> to me. It has to be done in other languages because they don't provide >> multiple return values; unfortunately this can make code hard to read. >> But since Ruby actually has mutliple returns, I personally prefer to do >> it that way. > > I agree - arguments = input, return value(s) = output generally makes > stuff clear. > That kind of simple function is a great idea most of the time, but there > are cases where the obvious thing (obvious -> POLS) is for a side-effect > to occur. Good examples of this in standard Ruby include Kernel::puts and > String::sub! Where exactly to these return something to the caller other than the instanece itself? Note: I did not oppose side effects. I just don't like to return values via (changed) command line arguments. Of cours, if I have a method remove_all_occurrences_of_1(enum) then it's quite "obvious" that since all 1's are removed from the Enumerable the collection will have changed afterwards. But for that to happen we do not need to return "enum" somehow because the reference itself did not change. Hope that clarifies it. Kind regards robert