On Tue, Jul 18, 2017 at 10:10 PM, Eliot Miranda <eliot.miranda at gmail.com>
wrote:

> Hi Bert,
>
> On Tue, Jul 18, 2017 at 7:51 AM, Bert Freudenberg <bert at freudenbergs.de>
> wrote:
>
>> ​+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.
>

Right.​

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?


> 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.

​- Bert -​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20170718/4ed0b82e/attachment.html>