HaloO, Darren Duncan wrote:
Long story shortened, if we consider the point in time where an "immutable" object's constructor returns as being when the object is born, then we have no problem. Any type of object is thereby immutable if it can not be changed after its constructor returns.
My lines of thinking about programs run along yours with values existing eternally. But I think of the constructor of a constant not as building the object in the first place *but* as making it part of the current program. I imagine a conceptual membrane in type space that encloses the program and shrinks and grows while it is running. Mutability says something about the membrane's changeability *not* about the value. This inside/outside metapher is very strong. A mutable object is an aggregate of changing pieces of the membrane in a fixed membrane frame of program real estate. After understanding values as above, I just want to add that the type of objects makes statements about all possible values of its class. The runtime component of the type system enforces all contstraints placed on values of the type while the program attempts to modify the membrane to catch the values into it or some such :) In yet another view an object conceptually is a One Junction over all possible values. At any given time in a program flow the program space representing the object has a well defined value. If it matches the intents of the programmer remains to be seen! --
