[Vm-dev] Re: [squeak-dev] The Trunk: System-eem.803.mcz

Tobias Pape Das.Linux at gmx.de
Thu Mar 3 10:08:24 UTC 2016


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

> 
> Hi Tobias,
> 
>> On Mar 3, 2016, at 12:10 AM, Tobias Pape <Das.Linux at 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 at 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]]!
>> 



More information about the Vm-dev mailing list