From: "Aleksi Niemelä" <aleksi.niemela@...>
Date: 2000-07-14T12:45:51+02:00
Subject: [ruby-talk:04004] Re: Array.uniq! returning nil

Jo asks:
> |But I don't understand your decision to _not_ follow Scheme tradition

Matz responds: 
> The reason is, as a totally object-oriented language, Ruby has too
> many operations with side-effect.  If I choose Scheme way of bang
> usage, Ruby programs are filled with bangs.  That is ugly, at least
> not my taste.  That's why.

I like your view here! I think you're quite correct. First bang-methods were
new to me and I wanted to have them used consistently. Then I realised it
would cause the programs to be stabbed all over with these ugly attention
collectors. One would lose the interest to be alerted with '!' anymore. 

Then I understood that most of methods *are* self-modifying by nature, and
it's quite apparent when named well: array.delete_at(index) says it clearly.
So we really don't need bang-methods all over. Even if it's inconsistent
from a smalltalk point of view, it's consistent with other principle. 

That principle is to tag '!' to the method with self-modifying nature if
there's a counterpart method with the same basic semantics (function) but
without self-modifying nature.

Example case could be Array#reverse and reverse!, which function is easy to
guess and it works exactly in same way, just the object it operates upon is
different (in Array#reverse case it's the object returned by receiver.dup,
not the receiver itself).

Jo continues:
> |here? After all it's understandable, and it's easy to remember. 

This principle is understandable and easy to remember too.

But here's the catch. Ruby does not follow this principle all the time.

Array#uniq and Array#uniq! are mostly same but differ in possible returning
value types. The difference should be only that Array#uniq is
array.dup.uniq!, but actually it's more than that. Array#uniq can't return
nil, but Array#uniq! can. So the caller side have to be specifically adapted
to the used version. One can say:

  array=[1,2,3].uniq    # array refers to Array object [1,2,3]

but can't say

  array=[1,2,3].uniq!   # array refers to nil

and expect to have an array which refers always to an object which class is
Array.

Matz says:
> Hope this explains what I feel.

This explains a lot. Thank you. Now I can see how clear your thinking has
been here (too :).

Still I don't know if the fact that method! can return nil was just
introduced when needed (as someone pulled in some code to show it in this
thread), and the current functionality remains because there's loads of code
relying on it, or whether it was thought, and decided, to be inconsistent
with the principle I just phrased. (Perhaps because Ruby is following here
some other clean and simple priciple.)

	- Aleksi