Strings in Playground are read only in Pharo 9
Hi all,
strings in Playground are read only in Pharo 9.0 Build 1153 so that
'hello' at: 2 put: $a; yourself
ctrl+p
This throws an error:
„Modification forbidden: ‚hello‘ is read-only, hence its field cannot be modified with $a
which is actually a very nice error message but is this supposed to happen?
The example does work in Pharo 8 without problems.
Greetings
Markus
Markus,
'hello' is a literal string constant, part of the set of constants of a method (or a doit which like a temporary method disconnected from a class).
Constants like these are managed by the compiler and can be shared between different expressions to avoid duplication.
Changing such a constant is dangerous because it means you are changing static/compiled code. Consider a method like
name
^ 'Markus'
I could call this method and change the returned string destructively in place. Next time someone calls it, s/he would get the modified string. Even worse, s/he would not understand since the source code did not change.
In the past it was not possible to mark such strings as being constant, now we can. Which is a big win.
You can use #copy to get a string that you can modify.
'hello' copy at: 2 put: $a; yourself
HTH,
Sven
On 28 Feb 2021, at 00:50, Markus Wedel mail@markus-wedel.de wrote:
Hi all,
strings in Playground are read only in Pharo 9.0 Build 1153 so that
'hello' at: 2 put: $a; yourself
ctrl+p
This throws an error:
„Modification forbidden: ‚hello‘ is read-only, hence its field cannot be modified with $a
which is actually a very nice error message but is this supposed to happen?
The example does work in Pharo 8 without problems.
Greetings
Markus
Hello Sven,
thank you very much for this thorough explanation! I also think a string literal should be a constant.
But since I am new to Smalltalk I am reading a lot of documentation, and in the older documentation modification of a string was shown as an example. In fact this modification is still possible in Pharo 8.
But I am all for progress and evolution of Smalltalk for the better and this is how it was meant to be by it’s inventors.
Again thank you very much for your time
Markus
Von meinem iPad gesendet
Am 28.02.2021 um 10:57 schrieb Sven Van Caekenberghe sven@stfx.eu:
Markus,
'hello' is a literal string constant, part of the set of constants of a method (or a doit which like a temporary method disconnected from a class).
Constants like these are managed by the compiler and can be shared between different expressions to avoid duplication.
Changing such a constant is dangerous because it means you are changing static/compiled code. Consider a method like
name
^ 'Markus'
I could call this method and change the returned string destructively in place. Next time someone calls it, s/he would get the modified string. Even worse, s/he would not understand since the source code did not change.
In the past it was not possible to mark such strings as being constant, now we can. Which is a big win.
You can use #copy to get a string that you can modify.
'hello' copy at: 2 put: $a; yourself
HTH,
Sven
On 28 Feb 2021, at 00:50, Markus Wedel mail@markus-wedel.de wrote:
Hi all,
strings in Playground are read only in Pharo 9.0 Build 1153 so that
'hello' at: 2 put: $a; yourself
ctrl+p
This throws an error:
„Modification forbidden: ‚hello‘ is read-only, hence its field cannot be modified with $a
which is actually a very nice error message but is this supposed to happen?
The example does work in Pharo 8 without problems.
Greetings
Markus
For what it's worth, the ANSI Smalltalk standard says
"The protocols specified for literals do not include any messages
that modify the state of the literal objects.
The effect of sending a message to an object that is the value
of a literal that modifies the state of the literal is undefined."
This also includes trying to modify an array literal, and fiddling
with the bits of a large integer.
That is, according to the ANSI standard, 'abc' is a string but not
necessarily a String. I hope that is clear (:-).
On Sun, 28 Feb 2021 at 22:57, Sven Van Caekenberghe sven@stfx.eu wrote:
Markus,
'hello' is a literal string constant, part of the set of constants of a
method (or a doit which like a temporary method disconnected from a class).
Constants like these are managed by the compiler and can be shared between
different expressions to avoid duplication.
Changing such a constant is dangerous because it means you are changing
static/compiled code. Consider a method like
name
^ 'Markus'
I could call this method and change the returned string destructively in
place. Next time someone calls it, s/he would get the modified string. Even
worse, s/he would not understand since the source code did not change.
In the past it was not possible to mark such strings as being constant,
now we can. Which is a big win.
You can use #copy to get a string that you can modify.
'hello' copy at: 2 put: $a; yourself
HTH,
Sven
On 28 Feb 2021, at 00:50, Markus Wedel mail@markus-wedel.de wrote:
Hi all,
strings in Playground are read only in Pharo 9.0 Build 1153 so that
'hello' at: 2 put: $a; yourself
ctrl+p
This throws an error:
„Modification forbidden: ‚hello‘ is read-only, hence its field cannot be
modified with $a
which is actually a very nice error message but is this supposed to
happen?
The example does work in Pharo 8 without problems.
Greetings
Markus
I have a small Key/Value database that I have written for my Seaside apps. I have one Package - Family-Accounts which defines the classes for this database. I am now writing a new Seaside app (IPMSClacton) that will also need to use the database. How do I share the code between the two packages?
David
Totally Objects
I guess that the answer is to move the kv into its own package but I don't know how to refer from one package to another. Can anyone clarify for me.
Sent from my Huawei tablet
-------- Original Message --------
Subject: [Pharo-users] Sharing classes between packages
From: David Pennington
To: Any question about pharo is welcome
CC:
I have a small Key/Value database that I have written for my Seaside apps. I have one Package - Family-Accounts which defines the classes for this database. I am now writing a new Seaside app (IPMSClacton) that will also need to use the database. How do I share the code between the two packages?
David
Totally Objects
Hi David,
Indeed, you should move it to another package.
However, this package should either:
be in its own repository
load it with the initial project
In this case, you'd have to clone the whole initial project and
load only the package that you want to share, which can be quite big.
Either way, you'll have to tweak the baseline, as you can read about
here:
https://github.com/pharo-open-documentation/pharo-wiki/blob/master/General/Baselines.md
Hope this helps.
Pierre
On 01/03/2021 21:49, David@totallyobjects.com wrote:
I guess that the answer is to move the kv into its own package but I
don't know how to refer from one package to another. Can anyone
clarify for me.
Sent from my Huawei tablet
-------- Original Message --------
Subject: [Pharo-users] Sharing classes between packages
From: David Pennington
To: Any question about pharo is welcome
CC:
I have a small Key/Value database that I have written for my
Seaside apps. I have one Package - Family-Accounts which defines
the classes for this database. I am now writing a new Seaside app
(IPMSClacton) that will also need to use the database. How do I
share the code between the two packages?
David
Totally Objects