On Tue, Jul 18, 2017 at 2:22 PM, Bert Freudenberg <bert at freudenbergs.de>
wrote:

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

Almost.  One can still do

    someClass adoptInstance: aStatelessObject
    aStatelessObject becomeForward: anOtherObject
    aStatelessObject pin
    aStatelessObject unpin

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

_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20170719/6c12748f/attachment-0001.html>