RE: ruby-dev summary 16501-16750 (immutable?)

> From: TAKAHASHI Masayoshi
....
>   BigFloat was imported into Ruby's CVS, and there
>   was a discussion about Numeric's subclasses.
> 
>    * Numeric's subclass should be immutable.
>    * A 'immutable' class has no public method to change states
>      of its instances. Some methods such as instance_eval
>      can change the state.

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.

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.

>    * Object which is not a instance of subclass of Numeric
>      may have coerce.

Yes, this would be a great fit with Ruby's current Object-model. The
Comparable module might be a good candidate for the early adaptation of
this generalized coerce framework?

>
... 

/Christoph