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)?
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_declarati... [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]]!
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.
But locked is definitely the wrong word. To me it evokes notions of mutual exclusion and concurrency. 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
[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_declarati... [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]]!
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
[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_declarati... [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]]!
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
[2]: a) http://docs.racket-lang.org/reference/pairs.html "Pairs are
not mutable"
https://wiki.haskell.org/A_brief_introduction_to_Haskell#Immutable_declarati...
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 attemptto write, to immutable objects."
- "SmalltalkImage current supportsImmutability"
- ^(self vmParameterAt: 65)
ifNil: [false]ifNotNil:[:param| "In older VMs this is a boolean reflectingMULTIPLE_BYTECODE_SETS"
param isInteger "In newer VMs it is a set of integerflags, 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 reflectingMULTIPLE_BYTECODE_SETS"
param isInteger "In newer VMs it is a set of integerflags, bit 0 of which is MULTIPLE_BYTECODE_SETS"
ifTrue: [param anyMask: 1]ifFalse: [param]]!
Hello,
In VA Smalltalk it is also possible to mark an object as readonly. VA Smalltalk uses the following method names:: #isReadOnly #markReadOnly: aBoolean
If you try to update a readonly object you get a PrimErrReadOnly error.
Jan.
On Thu, Mar 3, 2016 at 1:34 PM, Clément Bera bera.clement@gmail.com wrote:
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
[2]: a) http://docs.racket-lang.org/reference/pairs.html "Pairs are
not mutable"
https://wiki.haskell.org/A_brief_introduction_to_Haskell#Immutable_declarati...
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 thatattempt to write, to immutable objects."
- "SmalltalkImage current supportsImmutability"
- ^(self vmParameterAt: 65)
ifNil: [false]ifNotNil:[:param| "In older VMs this is a boolean reflectingMULTIPLE_BYTECODE_SETS"
param isInteger "In newer VMs it is a set of integerflags, 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 reflectingMULTIPLE_BYTECODE_SETS"
param isInteger "In newer VMs it is a set of integerflags, bit 0 of which is MULTIPLE_BYTECODE_SETS"
ifTrue: [param anyMask: 1]ifFalse: [param]]!
vm-dev@lists.squeakfoundation.org
-
Clément Bera -
Eliot Miranda -
Jan van de Sandt -
Tobias Pape