in reply to
Re^3: The fallacy of the *requirement* for read-only instance variables.
in thread The fallacy of the *requirement* for read-only instance variables.
Considering that nothing comes from nothing, everything that has ever come into being had a "setter" of some type. Read-only doesn't exist, by that definition.
As far as I can see, persistence makes the case for the applicability of a ROIA in the role of unique id. When as stored object is reconstituted, will the object handle be exactly the same value as it was before? Obviously not, handles must be recycled or we would have run out by now. Therefore it could not serve this purpose. We don't need the horsepower or overhead of a method, there is nothing to calculate. The value rightly belongs to the object itself. Why not us an instance variable that can't be changed? Actually, if we are willing to shorten our attention span slightly, the unique id in the reconstituted object is an example of read-only.
What details are missing? I think we all understand the concept of a unique id and how they are used. Enough to know they are fundamental to relational databases, serializations schemes, object handles, etc. Do nothing? I think not.
How do you implement unique ids in objects without using an ROIA?