From: matz@... (Yukihiro Matsumoto)
Date: 2002-04-10T11:31:57+09:00
Subject: Re: ruby-dev summary 16501-16750 (immutable?)

Hi,

In message "RE: ruby-dev summary 16501-16750 (immutable?)"
    on 02/04/10, "Christoph" <chr_news@gmx.net> writes:

|May I throw in the fact that Python has a quite different take on this
|on this question?  As early (or late?) as version 2.0 Python adapted `in
|place' assignment operators, very similar to C++ *=,+=, etc. operators,
|and very different from Ruby's `convenience (fake?) in place' assignment
|operators.

I'm totally against Python's in-place (argumented) assignment.  The
operator "+=" and such work pretty differently depending on whether an
operand is mutable or not.  I feel it's too dangerous and the source
of confusion.  It's OK to make something mutable, but it should
certainly not any sort of assignment.

|It has become some ride of passage for Nubies seeing the light after
|coming to terms with the loss of C++'s beloved post-fix ++-operator,
|therefore it seems worthwhile pointing out that the exact same
|theoretical arguments justifying the immutability of numbers apply
|equally well to arrays and strings in fact most of Ruby's standard
|objects. The proposed sacrifice of Ruby's numerical efficiency on the
|altar of OO-purity (never mind I know I am execrating ;-) by policing
|all mutability loop holes is taking things too far imho.

It's not for OO-purity.  It's for consisntency of the number system.
And if you really want number efficiency, you can try NArray etc.

							matz.