Smalltalk › Pharo › Pharo Smalltalk Developers

Immutability support

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

48 messages Options

123

NorbertHartl

Immutability support

Does anyone know the state of immutability support in vm and image? The latest vm downloadable is compiled with

IMMUTABILITY=1

(Esteban said that). When I open a pharo6 image with this VM and do:

ASUser new
setIsReadOnlyObject: true;
name: 'foo'

with

ASUser>>#name: arg1
name := arg1

I don't get an exception. Is there something missing or am I not understanding?

Norbert

Denis Kudriashov

Re: Immutability support

2017-01-25 11:35 GMT+01:00 Norbert Hartl <[hidden email]>:

ASUser new
setIsReadOnlyObject: true

And why so ugly name? Why not #isReadOnlyObject:?

NorbertHartl

Re: Immutability support

Am 25.01.2017 um 11:40 schrieb Denis Kudriashov <[hidden email]>:

2017-01-25 11:35 GMT+01:00 Norbert Hartl <[hidden email]>:
ASUser new
setIsReadOnlyObject: true

And why so ugly name? Why not #isReadOnlyObject:?

To be honest I think #isReadOnlyObject: is worse :) isXXX is a prefix for testing methods. isXXX with an argument feels even more strange. I would rather have #beReadOnly

Norbert

Sven Van Caekenberghe-2

Re: Immutability support

> On 25 Jan 2017, at 11:47, Norbert Hartl <[hidden email]> wrote:
>
>
>> Am 25.01.2017 um 11:40 schrieb Denis Kudriashov <[hidden email]>:
>>
>>
>> 2017-01-25 11:35 GMT+01:00 Norbert Hartl <[hidden email]>:
>> ASUser new
>> setIsReadOnlyObject: true
>>
>> And why so ugly name? Why not #isReadOnlyObject:?
>
> To be honest I think #isReadOnlyObject: is worse :) isXXX is a prefix for testing methods. isXXX with an argument feels even more strange. I would rather have #beReadOnly

Yes, #beReadOnly

> Norbert

Denis Kudriashov

Re: Immutability support

In reply to this post by NorbertHartl

2017-01-25 11:47 GMT+01:00 Norbert Hartl <[hidden email]>:

To be honest I think #isReadOnlyObject: is worse :) isXXX is a prefix for testing methods. isXXX with an argument feels even more strange. I would rather have #beReadOnly

Now there is #beReadOnlyObject and #beWritableObject. Maybe for primitive it is better to use #primReadOnlyObject:.

It also raise another question: does these primitives support mirror approach? (when it can be called with receiver as first argument?)

Sven Van Caekenberghe-2

Re: Immutability support

> On 25 Jan 2017, at 11:55, Denis Kudriashov <[hidden email]> wrote:
>
>
> 2017-01-25 11:47 GMT+01:00 Norbert Hartl <[hidden email]>:
> To be honest I think #isReadOnlyObject: is worse :) isXXX is a prefix for testing methods. isXXX with an argument feels even more strange. I would rather have #beReadOnly
>
> Now there is #beReadOnlyObject and #beWritableObject. Maybe for primitive it is better to use #primReadOnlyObject:.

why the object suffix, everything is an object, right ?

the simplest wording is often the best, unless there is a good reason for something else.

> It also raise another question: does these primitives support mirror approach? (when it can be called with receiver as first argument?)

Denis Kudriashov

Re: Immutability support

2017-01-25 11:59 GMT+01:00 Sven Van Caekenberghe <[hidden email]>:

why the object suffix, everything is an object, right ?

I think problem that these names could be already in use by frameworks. I am sure #isReadOnly, #beReadOnly is used in many UI's. For example Margitte uses it

Denis Kudriashov

Re: Immutability support

2017-01-25 12:03 GMT+01:00 Denis Kudriashov <[hidden email]>:

I think problem that these names could be already in use by frameworks. I am sure #isReadOnly, #beReadOnly is used in many UI's. For example Margitte uses it

And probably Glorp

EstebanLM

Re: Immutability support

On 25 Jan 2017, at 12:04, Denis Kudriashov <[hidden email]> wrote:

2017-01-25 12:03 GMT+01:00 Denis Kudriashov <[hidden email]>:
I think problem that these names could be already in use by frameworks. I am sure #isReadOnly, #beReadOnly is used in many UI's. For example Margitte uses it

And probably Glorp

yes, but #setIsReadOnlyObject: deserves a place in the podium of ugly names :)

I thought the names were going to be like beWritable/beNotWritable/isWritable

which are not a lot better, but well…

Esteban

NorbertHartl

Re: Immutability support

Am 25.01.2017 um 12:16 schrieb Esteban Lorenzano <[hidden email]>:

On 25 Jan 2017, at 12:04, Denis Kudriashov <[hidden email]> wrote:

2017-01-25 12:03 GMT+01:00 Denis Kudriashov <[hidden email]>:
I think problem that these names could be already in use by frameworks. I am sure #isReadOnly, #beReadOnly is used in many UI's. For example Margitte uses it

And probably Glorp

yes, but #setIsReadOnlyObject: deserves a place in the podium of ugly names :)

Absolutely. And we are a really caring community because we care so much about a method name of a feature that does not work :)

Norbert

I thought the names were going to be like beWritable/beNotWritable/isWritable
which are not a lot better, but well…

Esteban

philippeback

Re: Immutability support

In reply to this post by NorbertHartl

Yes, exactly how it felt. Maybe #setImmutable would be more intention revealing.

Phil

On Wed, Jan 25, 2017 at 11:47 AM, Norbert Hartl <[hidden email]> wrote:

Am 25.01.2017 um 11:40 schrieb Denis Kudriashov <[hidden email]>:

2017-01-25 11:35 GMT+01:00 Norbert Hartl <[hidden email]>:
ASUser new
setIsReadOnlyObject: true

And why so ugly name? Why not #isReadOnlyObject:?

To be honest I think #isReadOnlyObject: is worse :) isXXX is a prefix for testing methods. isXXX with an argument feels even more strange. I would rather have #beReadOnly

Norbert

philippeback

Re: Immutability support

In reply to this post by NorbertHartl

So, beImmutable and beMutable seem pretty usable and not collision causing IMHO.

Phil

On Wed, Jan 25, 2017 at 12:19 PM, Norbert Hartl <[hidden email]> wrote:

Am 25.01.2017 um 12:16 schrieb Esteban Lorenzano <[hidden email]>:

On 25 Jan 2017, at 12:04, Denis Kudriashov <[hidden email]> wrote:

2017-01-25 12:03 GMT+01:00 Denis Kudriashov <[hidden email]>:
I think problem that these names could be already in use by frameworks. I am sure #isReadOnly, #beReadOnly is used in many UI's. For example Margitte uses it

And probably Glorp

yes, but #setIsReadOnlyObject: deserves a place in the podium of ugly names :)

Absolutely. And we are a really caring community because we care so much about a method name of a feature that does not work :)

Norbert
I thought the names were going to be like beWritable/beNotWritable/isWritable
which are not a lot better, but well…

Esteban

EstebanLM

Re: Immutability support

but this is not real immutability, is like a write barrier, that’s why those method names were not chosen.

Esteban

On 25 Jan 2017, at 12:37, [hidden email] wrote:

So, beImmutable and beMutable seem pretty usable and not collision causing IMHO.

Phil

On Wed, Jan 25, 2017 at 12:19 PM, Norbert Hartl <[hidden email]> wrote:

Am 25.01.2017 um 12:16 schrieb Esteban Lorenzano <[hidden email]>:

On 25 Jan 2017, at 12:04, Denis Kudriashov <[hidden email]> wrote:

2017-01-25 12:03 GMT+01:00 Denis Kudriashov <[hidden email]>:
I think problem that these names could be already in use by frameworks. I am sure #isReadOnly, #beReadOnly is used in many UI's. For example Margitte uses it

And probably Glorp

yes, but #setIsReadOnlyObject: deserves a place in the podium of ugly names :)

Absolutely. And we are a really caring community because we care so much about a method name of a feature that does not work :)

Norbert
I thought the names were going to be like beWritable/beNotWritable/isWritable
which are not a lot better, but well…

Esteban

CyrilFerlicot

Re: Immutability support

On 25/01/2017 12:59, Esteban Lorenzano wrote:
> but this is not real immutability, is like a write barrier, that’s why
> those method names were not chosen.
>

Then why not #(des)activateWriteBarrier?

> Esteban
>
>

--
Cyril Ferlicot

http://www.synectique.eu

2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France

signature.asc (817 bytes) Download Attachment

Clément Béra

Re: Immutability support

In reply to this post by NorbertHartl

On Wed, Jan 25, 2017 at 11:35 AM, Norbert Hartl <[hidden email]> wrote:

Does anyone know the state of immutability support in vm and image? The latest vm downloadable is compiled with

IMMUTABILITY=1

(Esteban said that). When I open a pharo6 image with this VM and do:

ASUser new
setIsReadOnlyObject: true;
name: 'foo'

with

ASUser>>#name: arg1
name := arg1

I don't get an exception. Is there something missing or am I not understanding?

Hi Norbert,

Thank you very much for looking read-only objects.

When mutating an instance variable, the VM triggers a call-back that by default does nothing. In your case, running your code does not raise an exception but the object should not be modified either. If you want an exception, you need to change the call-back code, i.e., the method Object>>#attemptToAssign: value withIndex: index. For example, you could write:

Object>>#attemptToAssign: value withIndex: index

| process |

self notify: 'object changed !'.

process := Processor activeProcess.

[ process suspendedContext: process suspendedContext sender ] forkAt: Processor activePriority + 1.

Processor yield.

Then, your code should open a notification window with 'object changed', and proceeding keeps running the code without mutating the object.

One needs to build a ModificationTracker framework on top of the VM support I introduced. Multiple things are required, like default behavior in this call-back and in primitive failure code. I am willing to support and help anyone willing to build such a framework, but I won't build it myself.

If you have any other questions or if you find bug don't hesitate to ask further questions

Best,

PS: Make sure "Smalltalk vm supportsWriteBarrier" answers true in your system, if this is not the case it means the VM does not support read-only objects.

Clement

Norbert

Clément Béra

Re: Immutability support

In reply to this post by Denis Kudriashov

On Wed, Jan 25, 2017 at 11:55 AM, Denis Kudriashov <[hidden email]> wrote:

2017-01-25 11:47 GMT+01:00 Norbert Hartl <[hidden email]>:
To be honest I think #isReadOnlyObject: is worse :) isXXX is a prefix for testing methods. isXXX with an argument feels even more strange. I would rather have #beReadOnly

Now there is #beReadOnlyObject and #beWritableObject. Maybe for primitive it is better to use #primReadOnlyObject:.

It also raise another question: does these primitives support mirror approach? (when it can be called with receiver as first argument?)

Yes I made sure the mirror approach works. Even better, there are tests ensuring that it works. You can see in the class WriteBarrierTest that objects can become read-only through an instance of TTMirror, look for example into the users of TTMirror>>#setIsReadOnlyObjectOf: object to: boolean.

Clément Béra

Re: Immutability support

In reply to this post by Denis Kudriashov

Hi again.

On Wed, Jan 25, 2017 at 12:04 PM, Denis Kudriashov <[hidden email]> wrote:

2017-01-25 12:03 GMT+01:00 Denis Kudriashov <[hidden email]>:
I think problem that these names could be already in use by frameworks. I am sure #isReadOnly, #beReadOnly is used in many UI's. For example Margitte uses it

And probably Glorp

The only thing we (the VM developers) care is that we have only 2 primitives, 163 to check is an object is read-only and 164 to change the read-only property of an object. We do not want to have #beReadOnlyObject and #beWritableObject as 2 different primitives, we prefer having only one primitive to mutate the state, which is currently in the Object>>#setIsReadOnlyObject: method.

The Pharo community is free to pick the names they like for their primitives. We tried to use #isReadOnly, #isWritable and #beReadOnly, but as Denis mentioned, there were conflicts with other frameworks. If you rename Object>>#attemptToAssign:withIndex:, don't forget to update the special object array with the new selector.

philippeback

Re: Immutability support

In reply to this post by Clément Béra

The "latest" Windows VM I do use has no such method.

Virtual Machine

---------------

C:\Users\Philippe\Dropbox\Sibelga\JiraAutomation\Pharo5.0\latestvm\pharo.exe

CoInterpreter * VMMaker.oscog-eem.2090 uuid: 63a161b9-17e1-4911-a89a-1687d9ba9a1a Jan 15 2017

StackToRegisterMappingCogit * VMMaker.oscog-eem.2090 uuid: 63a161b9-17e1-4911-a89a-1687d9ba9a1a Jan 15 2017

VM: 201701151442 https://github.com/pharo-project/pharo-vm.git $ Date: Sun Jan 15 15:42:39 2017 +0100 $ Plugins: 201701151442 https://github.com/pharo-project/pharo-vm.git $

Win32 built on Jan 15 2017 15:59:52 CUT Compiler: 5.4.0

VMMaker versionString VM: 201701151442 https://github.com/pharo-project/pharo-vm.git $ Date: Sun Jan 15 15:42:39 2017 +0100 $ Plugins: 201701151442 https://github.com/pharo-project/pharo-vm.git $

CoInterpreter * VMMaker.oscog-eem.2090 uuid: 63a161b9-17e1-4911-a89a-1687d9ba9a1a Jan 15 2017

StackToRegisterMappingCogit * VMMaker.oscog-eem.2090 uuid: 63a161b9-17e1-4911-a89a-1687d9ba9a1a Jan 15 2017

On Wed, Jan 25, 2017 at 1:54 PM, Clément Bera <[hidden email]> wrote:

On Wed, Jan 25, 2017 at 11:35 AM, Norbert Hartl <[hidden email]> wrote:
Does anyone know the state of immutability support in vm and image? The latest vm downloadable is compiled with

IMMUTABILITY=1

(Esteban said that). When I open a pharo6 image with this VM and do:

ASUser new
setIsReadOnlyObject: true;
name: 'foo'

with

ASUser>>#name: arg1
name := arg1

I don't get an exception. Is there something missing or am I not understanding?

Hi Norbert,

Thank you very much for looking read-only objects.

When mutating an instance variable, the VM triggers a call-back that by default does nothing. In your case, running your code does not raise an exception but the object should not be modified either. If you want an exception, you need to change the call-back code, i.e., the method Object>>#attemptToAssign: value withIndex: index. For example, you could write:

Object>>#attemptToAssign: value withIndex: index
| process |
self notify: 'object changed !'.
process := Processor activeProcess.
[ process suspendedContext: process suspendedContext sender ] forkAt: Processor activePriority + 1.
Processor yield.

Then, your code should open a notification window with 'object changed', and proceeding keeps running the code without mutating the object.

One needs to build a ModificationTracker framework on top of the VM support I introduced. Multiple things are required, like default behavior in this call-back and in primitive failure code. I am willing to support and help anyone willing to build such a framework, but I won't build it myself.

If you have any other questions or if you find bug don't hesitate to ask further questions

Best,

PS: Make sure "Smalltalk vm supportsWriteBarrier" answers true in your system, if this is not the case it means the VM does not support read-only objects.

Clement

Norbert

Clément Béra

Re: Immutability support

In reply to this post by EstebanLM

On Wed, Jan 25, 2017 at 12:59 PM, Esteban Lorenzano <[hidden email]> wrote:

but this is not real immutability, is like a write barrier, that’s why those method names were not chosen.

As Esteban mentioned, read-only objects are not immutable objects, that's why we didn't use these names. This followed a lot of discussion with many mails (read-only objects are working for a year now, so we had time to discuss) and I don't think we should discuss again this topic.

Esteban

On 25 Jan 2017, at 12:37, [hidden email] wrote:

So, beImmutable and beMutable seem pretty usable and not collision causing IMHO.

Phil

On Wed, Jan 25, 2017 at 12:19 PM, Norbert Hartl <[hidden email]> wrote:

Am 25.01.2017 um 12:16 schrieb Esteban Lorenzano <[hidden email]>:

On 25 Jan 2017, at 12:04, Denis Kudriashov <[hidden email]> wrote:

2017-01-25 12:03 GMT+01:00 Denis Kudriashov <[hidden email]>:
I think problem that these names could be already in use by frameworks. I am sure #isReadOnly, #beReadOnly is used in many UI's. For example Margitte uses it

And probably Glorp

yes, but #setIsReadOnlyObject: deserves a place in the podium of ugly names :)

Absolutely. And we are a really caring community because we care so much about a method name of a feature that does not work :)

Norbert
I thought the names were going to be like beWritable/beNotWritable/isWritable
which are not a lot better, but well…

Esteban

Clément Béra

Re: Immutability support

In reply to this post by philippeback

I introduced the method #supportsWriteBarrier in Pharo 6.

You can backport it if you want:

VirtualMachine>>#supportsWriteBarrier

"Answer whether the VM observes the per-object read-only flag and consequently

aborts writes to inst vars of, and fails primitives that attempt to write, to read-only objects."

^(self parameterAt: 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]]

On Wed, Jan 25, 2017 at 2:06 PM, [hidden email] <[hidden email]> wrote:

The "latest" Windows VM I do use has no such method.

Virtual Machine
---------------
C:\Users\Philippe\Dropbox\Sibelga\JiraAutomation\Pharo5.0\latestvm\pharo.exe
CoInterpreter * VMMaker.oscog-eem.2090 uuid: 63a161b9-17e1-4911-a89a-1687d9ba9a1a Jan 15 2017
StackToRegisterMappingCogit * VMMaker.oscog-eem.2090 uuid: 63a161b9-17e1-4911-a89a-1687d9ba9a1a Jan 15 2017
VM: 201701151442 https://github.com/pharo-project/pharo-vm.git $ Date: Sun Jan 15 15:42:39 2017 +0100 $ Plugins: 201701151442 https://github.com/pharo-project/pharo-vm.git $

Win32 built on Jan 15 2017 15:59:52 CUT Compiler: 5.4.0
VMMaker versionString VM: 201701151442 https://github.com/pharo-project/pharo-vm.git $ Date: Sun Jan 15 15:42:39 2017 +0100 $ Plugins: 201701151442 https://github.com/pharo-project/pharo-vm.git $
CoInterpreter * VMMaker.oscog-eem.2090 uuid: 63a161b9-17e1-4911-a89a-1687d9ba9a1a Jan 15 2017
StackToRegisterMappingCogit * VMMaker.oscog-eem.2090 uuid: 63a161b9-17e1-4911-a89a-1687d9ba9a1a Jan 15 2017

On Wed, Jan 25, 2017 at 1:54 PM, Clément Bera <[hidden email]> wrote:

On Wed, Jan 25, 2017 at 11:35 AM, Norbert Hartl <[hidden email]> wrote:
Does anyone know the state of immutability support in vm and image? The latest vm downloadable is compiled with

IMMUTABILITY=1

(Esteban said that). When I open a pharo6 image with this VM and do:

ASUser new
setIsReadOnlyObject: true;
name: 'foo'

with

ASUser>>#name: arg1
name := arg1

I don't get an exception. Is there something missing or am I not understanding?

Hi Norbert,

Thank you very much for looking read-only objects.

When mutating an instance variable, the VM triggers a call-back that by default does nothing. In your case, running your code does not raise an exception but the object should not be modified either. If you want an exception, you need to change the call-back code, i.e., the method Object>>#attemptToAssign: value withIndex: index. For example, you could write:

Object>>#attemptToAssign: value withIndex: index
| process |
self notify: 'object changed !'.
process := Processor activeProcess.
[ process suspendedContext: process suspendedContext sender ] forkAt: Processor activePriority + 1.
Processor yield.

Then, your code should open a notification window with 'object changed', and proceeding keeps running the code without mutating the object.

One needs to build a ModificationTracker framework on top of the VM support I introduced. Multiple things are required, like default behavior in this call-back and in primitive failure code. I am willing to support and help anyone willing to build such a framework, but I won't build it myself.

If you have any other questions or if you find bug don't hesitate to ask further questions

Best,

PS: Make sure "Smalltalk vm supportsWriteBarrier" answers true in your system, if this is not the case it means the VM does not support read-only objects.

Clement

Norbert

123