Ian Marsman wrote:
> 
> Is there any reason that in-place functions like gsub! and strip! return either
> the modified string or nil? The nil part is problematic.

methods with '!' are considered dangerous - only use them if you
know what you are doing...

But in general, 'nil' is returned because for example, that is the only
way to detect that nothing changed. This is not applicable in all
cases; sort! will return a value even if there is no change.

[ruby-talk: 02331]
>>>
In Ruby, exclamation mark means `MORE dangerous',
or `may cause surprise' than non-bang counterpart, i.g. in-place
modification by `gsub!' may let you surprise, comparing copying
`gsub'.
<<<

See also  [ruby-talk:03961]

> A function
> should do no harm and leave the string as it found it if nothing is
> found, I think. Their non-inline versions don't return nil if nothing was
> found. This behaviour makes these functions untrustable for me.
> Has this complaint ever been voiced before?

yes. But beforehand, a problem became apparent in not being
able to tell, for example, if something had changed.

[ruby-talk:6969] 
>>>
|Should the return value of mutating methods (syntactically indicated with a
|suffix 'bang') be specified?  Should they return value be nil or the object
|being modified?

There are three reasons for current behavior:

  (1) effectiveness; there's no effective way to tell if modification
      is happened.  separate check would be costly on many cases.

  (2) safty; since bang methods have side-effect, they often make
      programmers surprise when he finds an object referenced from
      another variable modified.  bang methods are more dangerous than
      one might think.  I know returning nil makes chaining harder,
      but I think it's worthy.

  (3) backward compatibility; there're already too many programs
      depend on this behavior.

MAEDA Shugo suggested me at the conference letting them return boolean
values, thus making bang chaining impossible.  It was attractive for
me, since it frees me from this kind of discussion for ever. ;-)

I think I have to mention two more things:

  (a) I'm not going to put bangs to ALL destructive methods like
      Scheme.  It's consistent, but makes Ruby programs too ugly.

  (b) I don't claim ALL bang methods should return nil if no
      modification happens (yet); for example, reverse! and sort!
      might be exceptions.

Hope this helps clarify my policy. 
                                                       matz.
<<<


Guy N. Hurst

-- 
HurstLinks Web Development    http://www.hurstlinks.com/
Norfolk, VA  23510            (757)623-9688 FAX 623-0433
PHP/MySQL - Ruby/Perl - HTML/Javascript