What would memory management have to do with it? That seems orthogonal to his point.

If you have to do your own memory management the first thing people reach for is reference counting. Reference counting means maintaining state and directly contradicts immutable objects.

So immutable objects only really work if you've got some kind of garbage collection available.

Maintaining mutable metadata for objects doesn't preclude having immutable objects. The object's value doesn't change when someone wants to inc/dec its refcount.

The strategy discussed involved lots of creating new objects that were the same as an old object but with one more piece of data. If you're using a reference counting implementation then every one of those methods needs to know about, and adjust, all of the reference counts that the object points to. This kind of busy accounting work is error-prone, and does a lot to undo the simplicity that you're trying to achieve with this methodology.

Why? Garbage collection is nothing more than implicit, runtime-managed refcounting.

Not so. A refcounting scheme cannot collect circular garbage, garbage collection can.

In any case the point is that an object's reference count is a piece of internal state that is externally manipulated.

Yes, I know there are differences, but many of the principles are similar. I decided not to write a treatise on GC ^_~.

So this is more of a internal vs. external state thing. Refcounting breaks the purity of the interface and requires you to think about memory management. Sure, I can see why you'd find that unacceptable and would break this model of programming. But I'm a C guy, so that doesn't really bother me, I guess ^_^.

He's making shallow copies of all of his objects and many of them.