<div dir="ltr">Hello,<div><br></div><div>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.</div><div><br></div><div>We can do two things: </div><div>- change the image-side APIs only, which is easy to do (<font face="monospace, monospace">#isImmutable</font><font face="arial, helvetica, sans-serif"> => </font><font face="monospace, monospace">#isReadOnly</font> and co).</div><div>- change the terminology in the VM, which is a bit more complex and error prone.</div><div><br></div><div>So if, and only if, there is a community agreement on a new terminology, I think we could change at least the image-side.</div><div><br></div><div>I like the <font face="monospace, monospace">isReadOnly</font> or <font face="monospace, monospace">hasWriteBarrier</font> terminologies myself, but I don't mind if the community decides to choose another terminology. </div><div><br></div><div>Regards</div><div><br></div><div>Clement</div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-03-03 11:08 GMT+01:00 Tobias Pape <span dir="ltr"><<a href="mailto:Das.Linux@gmx.de" target="_blank">Das.Linux@gmx.de</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
<br>
On 03.03.2016, at 09:56, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>> wrote:<br>
<br>
><br>
> Hi Tobias,<br>
><br>
>> On Mar 3, 2016, at 12:10 AM, Tobias Pape <<a href="mailto:Das.Linux@gmx.de">Das.Linux@gmx.de</a>> wrote:<br>
>><br>
>><br>
>> Hi all, Hi Eliot, Hi Clément<br>
>><br>
>> Well, you know I'm the opponent here regarding the Immutability naming.<br>
>> I hate that I have to come back to the naming thing here once again.<br>
>> But it is rather important for me, since I work on immutability concepts<br>
>> that are unlike what immutability would mean here. I think it is also<br>
>> important to know that immutability in most other languages means<br>
>> "it won't change whatsoever" (including OCaml[1], Racket[2],<br>
>> Haskell[3], or object-oriented programming in general[4])<br>
>><br>
>> Now, I see the need, usefulness, and practical implementation for objects<br>
>> that cannot be written and hence throw an error, which _then_ can be<br>
>> circumvented/made be writable. I'm all for it and I like it. Except<br>
>> for the name.<br>
>><br>
>> As Clément put it:<br>
>> "As argued on the virtual machine mailing list, we are talking<br>
>> about a write-barrier more than immutability itself."<br>
>><br>
>><br>
>> I would hence propose to name those objects<br>
>><br>
>> locked objects<br>
>><br>
>> with the accompanying Someone-tries-to-write-that-Error named<br>
>><br>
>> ObjectIsLockedError<br>
>><br>
>> and the state-change messages<br>
>><br>
>> Object>>lock<br>
>> Object>>unlock<br>
>><br>
>> and likewise the VM-information<br>
>><br>
>> SmalltalkImage>>supportsLockedObjects<br>
>><br>
>> I know, re-iterating this is tedious, but it will avoid unmet<br>
>> expectations by newcomers from other languages as well as<br>
>> name clashes with actual immutability implementations (how should<br>
>> we name those, then)?<br>
><br>
> 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.<br>
<br>
</div></div>I completely understand that<br>
<span class=""><br>
><br>
> But locked is definitely the wrong word. To me it evokes notions of mutual exclusion and concurrency.<br>
<br>
</span>Yeah, but I thought more of the 'door lock' lock.<br>
What about latch? It fits the the door lock metaphor but also the electronic meaning fits:<br>
"a circuit which retains whatever output state results from a momentary input signal until reset by another signal."<br>
<br>
Best regards<br>
<span class="HOEnZb"><font color="#888888"> -Tobias<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
> 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?<br>
<br>
<br>
<br>
><br>
>><br>
>> With apologies<br>
>> -Tobias<br>
>><br>
>><br>
>> [1]: <a href="http://typeocaml.com/2015/01/02/immutable/" rel="noreferrer" target="_blank">http://typeocaml.com/2015/01/02/immutable/</a><br>
>> [2]: a) <a href="http://docs.racket-lang.org/reference/pairs.html" rel="noreferrer" target="_blank">http://docs.racket-lang.org/reference/pairs.html</a> "Pairs are not mutable"<br>
>> b) <a href="http://docs.racket-lang.org/reference/strings.html" rel="noreferrer" target="_blank">http://docs.racket-lang.org/reference/strings.html</a><br>
>> [3]: <a href="https://wiki.haskell.org/A_brief_introduction_to_Haskell#Immutable_declarations" rel="noreferrer" target="_blank">https://wiki.haskell.org/A_brief_introduction_to_Haskell#Immutable_declarations</a><br>
>> [4]: <a href="https://en.wikipedia.org/wiki/Immutable_object" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Immutable_object</a><br>
>><br>
>>> On 03.03.2016, at 03:19, <a href="mailto:commits@source.squeak.org">commits@source.squeak.org</a> wrote:<br>
>>><br>
>>> Eliot Miranda uploaded a new version of System to project The Trunk:<br>
>>> <a href="http://source.squeak.org/trunk/System-eem.803.mcz" rel="noreferrer" target="_blank">http://source.squeak.org/trunk/System-eem.803.mcz</a><br>
>>><br>
>>> ==================== Summary ====================<br>
>>><br>
>>> Name: System-eem.803<br>
>>> Author: eem<br>
>>> Time: 2 March 2016, 7:18:21.713694 pm<br>
>>> UUID: 934ce776-0717-469b-8818-300954393791<br>
>>> Ancestors: System-bf.802<br>
>>><br>
>>> Add getters that answer whether the VM supports immutability or multiple bytecode sets.<br>
>>><br>
>>> =============== Diff against System-bf.802 ===============<br>
>>><br>
>>> Item was added:<br>
>>> + ----- Method: SmalltalkImage>>supportsImmutability (in category 'system attributes') -----<br>
>>> + supportsImmutability<br>
>>> + "Answer whether the VM observes the per-object immutability flag and consequently<br>
>>> + aborts writes to inst vars of, and fails primitives that attempt to write, to immutable objects."<br>
>>> + "SmalltalkImage current supportsImmutability"<br>
>>> +<br>
>>> + ^(self vmParameterAt: 65)<br>
>>> + ifNil: [false]<br>
>>> + ifNotNil:<br>
>>> + [:param| "In older VMs this is a boolean reflecting MULTIPLE_BYTECODE_SETS"<br>
>>> + param isInteger "In newer VMs it is a set of integer flags, bit 1 of which is IMMUTABILITY"<br>
>>> + ifTrue: [param anyMask: 2]<br>
>>> + ifFalse: [false]]!<br>
>>><br>
>>> Item was added:<br>
>>> + ----- Method: SmalltalkImage>>supportsMultipleBytecodeSets (in category 'system attributes') -----<br>
>>> + supportsMultipleBytecodeSets<br>
>>> + "Answer whether the VM supports multiple bytecodeSets."<br>
>>> + "SmalltalkImage current supportsMultipleBytecodeSets"<br>
>>> +<br>
>>> + ^(self vmParameterAt: 65)<br>
>>> + ifNil: [false]<br>
>>> + ifNotNil:<br>
>>> + [:param| "In older VMs this is a boolean reflecting MULTIPLE_BYTECODE_SETS"<br>
>>> + param isInteger "In newer VMs it is a set of integer flags, bit 0 of which is MULTIPLE_BYTECODE_SETS"<br>
>>> + ifTrue: [param anyMask: 1]<br>
>>> + ifFalse: [param]]!<br>
>><br>
<br>
</div></div></blockquote></div><br></div>