[squeak-dev] Immutability and become
eliot.miranda at gmail.com
Wed Jul 19 21:06:55 UTC 2017
On Tue, Jul 18, 2017 at 2:22 PM, Bert Freudenberg <bert at freudenbergs.de>
> On Tue, Jul 18, 2017 at 10:10 PM, Eliot Miranda <eliot.miranda at gmail.com>
>> Hi Bert,
>> On Tue, Jul 18, 2017 at 7:51 AM, Bert Freudenberg <bert at freudenbergs.de>
>>> +1 for making the whole object graph be immutable.
>> This really doesn't make sense as it prevents any kind of change at all,
>> e.g. to the class hierarchy, and as Nicolas points out, prevents updating
>> objects if their class definitions are modified.
>> When we added "immutability" to VisualWorks (actually read-only objects)
>> we held off, and made only literals immutable. I'd like to see us make
>> CompiledMethods immutable too, but this wold introduce complications in
>> condensing changes/sources, adding/deleting breakpoints, etc. One can
>> provide an exception handler or a beMutableWhile: facility to make it easy
>> to temporarily make read-only objects writable.
> Or are you meaning that when an object is made immutable all its sub-state
>> is made immutable too? (An idea I have no problems with,
> Yes, that. Which means that immediates and nil/true/false should become
> immutable too. In fact, isn't any stateless object already immutable?
Almost. One can still do
someClass adoptInstance: aStatelessObject
aStatelessObject becomeForward: anOtherObject
provided it does't imply that classes can't change).
> The class should not be made immutable, agreed, but you shouldn't be
> able change the shape of instances, me thinks.
There are circumstances where that isn't the right thing to do, because
read-only-ness can be overloaded:
- Object-to-database mappers may set read-only-ness on objects to intercept
modifications (e.g. to add objects to a "to be written back" set). It
would be the manager's responsibility to handle the necessary temporary
relaxation of read-only-ness when an object read-only for the purposes of
the mapper has its shape changed.
- Debuggers may set read-only-ness to catch assignments.
Hence the exception raised for read-only violations needs to be rich enough
to allow these kinds of things. The idea is to have a read-only-ness
manager that registers managers for objects, and defers to the relevant
manager(s) to handle read-only-ness on error.
But since there will always be the primitives to set and unset
read-only-ness, read-only-ness may not be in effect for the entirety of an
object's lifetime, only most of the time.
- Bert -
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev