Smalltalk › Pharo › Pharo Smalltalk Users

Strings in Playground are read only in Pharo 9

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

7 messages Options

Markus Wedel

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

Sven Van Caekenberghe-2

Re: Strings in Playground are read only in Pharo 9

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 <[hidden email]> 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

Markus Wedel

Re: Strings in Playground are read only in Pharo 9

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 <[hidden email]>:
>
> 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 <[hidden email]> 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

Richard O'Keefe

Re: Strings in Playground are read only in Pharo 9

In reply to this post by Sven Van Caekenberghe-2

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 <[hidden email]> 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 <[hidden email]> 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

Long Haired David

Sharing classes between packages

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

David
Totally Objects
Doing Smalltalk since 1989

Long Haired David

Re: Sharing classes between packages

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

David
Totally Objects
Doing Smalltalk since 1989

hogoww

Re: Sharing classes between packages

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, [hidden email] 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