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

Thu Mar 3 12:34:06 UTC 2016

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 at gmx.de>:

>
>
> 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]]!
> >>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160303/c69016b2/attachment.htm