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
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/B... 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
participants (6)
-
David Pennington -
David＠totallyobjects.com
-
hogoww -
Markus Wedel -
Richard O'Keefe -
Sven Van Caekenberghe