Hello,

I agree that there is a naming problem. However, we decided to let it this way because that is the VisualWorks terminology and we wanted to be compatible.

We can do two things: 

- change the image-side APIs only, which is easy to do (#isImmutable => #isReadOnly and co).

- change the terminology in the VM, which is a bit more complex and error prone.

So if, and only if, there is a community agreement on a new terminology, I think we could change at least the image-side.

I like the isReadOnly or hasWriteBarrier terminologies myself, but I don't mind if the community decides to choose another terminology. 

Regards

Clement

2016-03-03 11:08 GMT+01:00 Tobias Pape <Das.Linux@gmx.de>:

On 03.03.2016, at 09:56, Eliot Miranda <eliot.miranda@gmail.com> wrote:

>
> Hi Tobias,
>
>> On Mar 3, 2016, at 12:10 AM, Tobias Pape <Das.Linux@gmx.de> wrote:
>>
>>
>> Hi all, Hi Eliot, Hi Clément
>>
>> Well, you know I'm the opponent here regarding the Immutability naming.
>> I hate that I have to come back to the naming thing here once again.
>> But it is rather important for me, since I work on immutability concepts
>> that are unlike what immutability would mean here. I think it is also
>> important to know that immutability in most other languages means
>> "it won't change whatsoever" (including OCaml[1], Racket[2],
>> Haskell[3], or object-oriented programming in general[4])
>>
>> Now, I see the need, usefulness, and practical implementation for objects
>> that cannot be written and hence throw an error, which _then_ can be
>> circumvented/made be writable. I'm all for it and I like it. Except
>> for the name.
>>
>> As Clément put it:
>>   "As argued on the virtual machine mailing list, we are talking
>>   about a write-barrier more than immutability itself."
>>
>>
>> I would hence propose to name those objects
>>
>>   locked objects
>>
>> with the accompanying Someone-tries-to-write-that-Error named
>>
>>   ObjectIsLockedError
>>
>> and the state-change messages
>>
>>   Object>>lock
>>   Object>>unlock
>>
>> and likewise the VM-information
>>
>>   SmalltalkImage>>supportsLockedObjects
>>
>> I know, re-iterating this is tedious, but it will avoid unmet
>> expectations by newcomers from other languages as well as
>> name clashes with actual immutability implementations (how should
>> we name those, then)?
>
> No need to apologize.  I had forgotten the naming issue in my delight at fixing the actual VM issue and being able to get an immutability^h^h^h^h^h^h^h^h^h^h^h^hwrite-protect fault.  Forgive me.

I completely understand that

>
> But locked is definitely the wrong word.  To me it evokes notions of mutual exclusion and  concurrency.

Yeah, but I thought more of the 'door lock' lock.
What about latch? It fits the the door lock metaphor but also the electronic meaning fits:
"a circuit which retains whatever output state results from a momentary input signal until reset by another signal."

Best regards
        -Tobias

> Tomorrow I'll rename the accessors etc to use the term read-only, so supportsReadOnlyObjects, beReadOnly isReadOnly and setReadOnly:.  Ok with you?  Any objections y'all?



>
>>
>> With apologies
>>   -Tobias
>>
>>
>> [1]: http://typeocaml.com/2015/01/02/immutable/
>> [2]: a) http://docs.racket-lang.org/reference/pairs.html "Pairs are not mutable"
>>    b) http://docs.racket-lang.org/reference/strings.html
>> [3]: https://wiki.haskell.org/A_brief_introduction_to_Haskell#Immutable_declarations
>> [4]: https://en.wikipedia.org/wiki/Immutable_object
>>
>>> On 03.03.2016, at 03:19, commits@source.squeak.org wrote:
>>>
>>> Eliot Miranda uploaded a new version of System to project The Trunk:
>>> http://source.squeak.org/trunk/System-eem.803.mcz
>>>
>>> ==================== Summary ====================
>>>
>>> Name: System-eem.803
>>> Author: eem
>>> Time: 2 March 2016, 7:18:21.713694 pm
>>> UUID: 934ce776-0717-469b-8818-300954393791
>>> Ancestors: System-bf.802
>>>
>>> Add getters that answer whether the VM supports immutability or multiple bytecode sets.
>>>
>>> =============== Diff against System-bf.802 ===============
>>>
>>> Item was added:
>>> + ----- Method: SmalltalkImage>>supportsImmutability (in category 'system attributes') -----
>>> + supportsImmutability
>>> +    "Answer whether the VM observes the per-object immutability flag and consequently
>>> +     aborts writes to inst vars of, and fails primitives that attempt to write, to immutable objects."
>>> +    "SmalltalkImage current supportsImmutability"
>>> +
>>> +    ^(self vmParameterAt: 65)
>>> +        ifNil: [false]
>>> +        ifNotNil:
>>> +            [:param| "In older VMs this is a boolean reflecting MULTIPLE_BYTECODE_SETS"
>>> +             param isInteger "In newer VMs it is a set of integer flags, bit 1 of which is IMMUTABILITY"
>>> +                ifTrue: [param anyMask: 2]
>>> +                ifFalse: [false]]!
>>>
>>> Item was added:
>>> + ----- Method: SmalltalkImage>>supportsMultipleBytecodeSets (in category 'system attributes') -----
>>> + supportsMultipleBytecodeSets
>>> +    "Answer whether the VM supports multiple bytecodeSets."
>>> +    "SmalltalkImage current supportsMultipleBytecodeSets"
>>> +
>>> +    ^(self vmParameterAt: 65)
>>> +        ifNil: [false]
>>> +        ifNotNil:
>>> +            [:param| "In older VMs this is a boolean reflecting MULTIPLE_BYTECODE_SETS"
>>> +             param isInteger "In newer VMs it is a set of integer flags, bit 0 of which is MULTIPLE_BYTECODE_SETS"
>>> +                ifTrue: [param anyMask: 1]
>>> +                ifFalse: [param]]!
>>