How do numbers fit into an OO framework. Number for which you can do a = b + c float = float + int a = i++ a < b There are several options: A/ Number objects can be immutable B/ Number objects can be mutable and assignment makes a copy C/ Number objects can be mutable and assignment takes a reference. If numbers are immutable, then what does i++ means? It must mean that a new object is created which has a value one more than that value of the object stored in i, and this object is then stored in i. So '++' operates on the name, not on the object. That seems a bit out of the spirit of oo where we operate on objects. If assignment makes a copy, then that is a problem for complex objects. We absolutely need by-reference handling for many things. So we would some-how needs different assignment for different objects. So take references, some take copies. The difference would have to be explicit e.g. a = b (reference) a := b (copy value) that is error prone. If mutable objects assign by reference then a = b while (a++ < b+5) ; would never stop, so the model is unexpected and error prone. So... where does that leave us? It seems that operators: a + b should really create new objects. Operators like a += b Really must change the left-hand object So assignments of number really really wants to be a value-copy. Maybe we use type tags to make it harder to go wrong. i.e. a := b Always makes 'a' a new object distinct from b. a =& b Always makes 'a' refer to the same object as b a = b is the same as =&, but is not allowed for 'bycopy' objects. Hmm.. what sort of assignment happens to formal variables in a function call. They should be by reference, but maybe changing the reference of a formal parameter shouldn't be permitted as that could lead to confusion? or maybe...... Instead of two difference sorts of assignment, we could have auto-dereference objects. If a type is strict-once, the there is guaranteed never to be any aliasing. So in a = b + c the '+' creates a new object with sum of b and c and it is assigned by reference to a. As there is no risk of an alias, no 'copy' is needed. But on a = b The object has a reference already, so to avoid counting the reference we make a new copy. So what happens in a function call where we want a by-reference parameter? We must be able to over-ride the auto-copy, but we still don't want reference counting. So we need to know that one reference will outlive the other. In that case we use '&' to make a reference. For a function call, it is clear that the actual parameter reference lasts longer. For a = &b we can probably use data-flow analysis to know when the object is destroyed. What about a[5] = &b; a[6] = &b; a[n] = 4; Hmmmm..