Smalltalk › Squeak › Squeak - Dev

Revisiting the deprecation of #asMutator vs #asSimpleSetter in 5.3 (sorry)

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

24 messages Options

Tim Johnson-2

Revisiting the deprecation of #asMutator vs #asSimpleSetter in 5.3 (sorry)

Hi,

First, before the rest of this complain-y message:

**Happy 2021 to everybody!**

Now to shamefully bring up a closed matter: in 2019 there was some
discussion on the mailing list that led to the deprecation of #asMutator.
Some portions of the discussion can be seen here:

http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201810.html
http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201843.html

Part of the argument was that "asMutator" and the notion of "mutators" was
not seen elsewhere in the image, and that it conflicted with work someone
was doing with GraphQL (?) which has its own notion of "mutators". Was
there other rationale?

In the meantime, various teams and projects will have to adapt their code.
And, users have been coping with various packages not loading seamlessly
in Squeak 5.3 due to this deprecation.

Squot: https://github.com/hpi-swa/Squot/issues/266
Seaside: https://github.com/SeasideSt/Seaside/issues/1195
Also Seaside: https://github.com/SeasideSt/Seaside/search?q=asMutator
HPI "Home Desktop System": http://wiki.squeak.org/squeak/2860

I'm sorry for bringing up a settled matter, and for grandstanding a bit
("at what price progress?"), but: was #asMutator deprecated because of
the argument that "mutators" are alien to Smalltalk and/or Squeak? If so,
I (respectfully) have a hard time accepting part of that argument. A
quick Google search turns up much literature.

"To add an accessor method and a mutator method" (2015)
https://medium.com/smalltalk-talk/getting-the-message-667d77ff78d

^ the above quotes & cites Alan Lovejoy's "Smalltalk: Getting The Message"
(2007)
https://web.archive.org/web/20150908201317/http://www.smalltalk.org/articles/article_20100320_a3_Getting_The_Message.html

See also: "simple accessor and mutator methods" (1998)
http://www.esug.org/data/Smalltalk/Historical/pocketst/whitepaper.html

and: ST/X's asMutator (in protocol 'converting')
https://live.exept.de/ClassDoc/classDocOf,CharacterArray

So: what is the long term strategy here? After methods are deprecated
and removed from the image, when those methods served the purpose of
compatibility with 3rd party packages and other Smalltalks, is it expected
that each outside package will either (a) maintain its own compatibility
layer, like Grease, or (b) implement the removed methods via class
extensions, thus possibly introducing conflicts?

Thanks,
Tim

marcel.taeumel

Re: Revisiting the deprecation of #asMutator vs #asSimpleSetter in 5.3 (sorry)

Hi Tim! :-)

> So: what is the long term strategy here? After methods are deprecated
> and removed from the image, when those methods served the purpose of
> compatibility with 3rd party packages and other Smalltalks, is it expected
> that each outside package will either (a) maintain its own compatibility
> layer, like Grease, or (b) implement the removed methods via class
> extensions, thus possibly introducing conflicts?

(a), I suppose, which is common for maintaining compatibility with several Smalltalk dialects and versions. Note that clients can turn off deprecation warnings before loading any not-updated package. When, at some point, a certain deprecation package is not in the release (or trunk) anymore, clients can re-load those packages as they remain available through source.squeak.org/trunk

Best,

Marcel

Am 02.01.2021 19:44:49 schrieb Tim Johnson <[hidden email]>:
Hi,

First, before the rest of this complain-y message:

**Happy 2021 to everybody!**

Now to shamefully bring up a closed matter: in 2019 there was some
discussion on the mailing list that led to the deprecation of #asMutator.
Some portions of the discussion can be seen here:

http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201810.html
http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201843.html

Part of the argument was that "asMutator" and the notion of "mutators" was
not seen elsewhere in the image, and that it conflicted with work someone
was doing with GraphQL (?) which has its own notion of "mutators". Was
there other rationale?

In the meantime, various teams and projects will have to adapt their code.
And, users have been coping with various packages not loading seamlessly
in Squeak 5.3 due to this deprecation.

Squot: https://github.com/hpi-swa/Squot/issues/266
Seaside: https://github.com/SeasideSt/Seaside/issues/1195
Also Seaside: https://github.com/SeasideSt/Seaside/search?q=asMutator
HPI "Home Desktop System": http://wiki.squeak.org/squeak/2860

I'm sorry for bringing up a settled matter, and for grandstanding a bit
("at what price progress?"), but: was #asMutator deprecated because of
the argument that "mutators" are alien to Smalltalk and/or Squeak? If so,
I (respectfully) have a hard time accepting part of that argument. A
quick Google search turns up much literature.

"To add an accessor method and a mutator method" (2015)
https://medium.com/smalltalk-talk/getting-the-message-667d77ff78d

^ the above quotes & cites Alan Lovejoy's "Smalltalk: Getting The Message"
(2007)
https://web.archive.org/web/20150908201317/http://www.smalltalk.org/articles/article_20100320_a3_Getting_The_Message.html

See also: "simple accessor and mutator methods" (1998)
http://www.esug.org/data/Smalltalk/Historical/pocketst/whitepaper.html

and: ST/X's asMutator (in protocol 'converting')
https://live.exept.de/ClassDoc/classDocOf,CharacterArray

So: what is the long term strategy here? After methods are deprecated
and removed from the image, when those methods served the purpose of
compatibility with 3rd party packages and other Smalltalks, is it expected
that each outside package will either (a) maintain its own compatibility
layer, like Grease, or (b) implement the removed methods via class
extensions, thus possibly introducing conflicts?

Thanks,
Tim

Tobias Pape

Re: Revisiting the deprecation of #asMutator vs #asSimpleSetter in 5.3 (sorry)

In reply to this post by Tim Johnson-2

Had I known the widespread understanding of #asMutator, I had objected more strongly against its removal -.-
Narf.

-t

> On 2. Jan 2021, at 19:44, Tim Johnson <[hidden email]> wrote:
>
> Hi,
>
> First, before the rest of this complain-y message:
>
> **Happy 2021 to everybody!**
>
> Now to shamefully bring up a closed matter: in 2019 there was some discussion on the mailing list that led to the deprecation of #asMutator. Some portions of the discussion can be seen here:
>
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201810.html
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201843.html
>
> Part of the argument was that "asMutator" and the notion of "mutators" was not seen elsewhere in the image, and that it conflicted with work someone was doing with GraphQL (?) which has its own notion of "mutators". Was there other rationale?
>
> In the meantime, various teams and projects will have to adapt their code. And, users have been coping with various packages not loading seamlessly in Squeak 5.3 due to this deprecation.
>
> Squot: https://github.com/hpi-swa/Squot/issues/266
> Seaside: https://github.com/SeasideSt/Seaside/issues/1195
> Also Seaside: https://github.com/SeasideSt/Seaside/search?q=asMutator
> HPI "Home Desktop System": http://wiki.squeak.org/squeak/2860
>
> I'm sorry for bringing up a settled matter, and for grandstanding a bit ("at what price progress?"), but: was #asMutator deprecated because of the argument that "mutators" are alien to Smalltalk and/or Squeak? If so, I (respectfully) have a hard time accepting part of that argument. A quick Google search turns up much literature.
>
> "To add an accessor method and a mutator method" (2015)
> https://medium.com/smalltalk-talk/getting-the-message-667d77ff78d
>
> ^ the above quotes & cites Alan Lovejoy's "Smalltalk: Getting The Message" (2007) https://web.archive.org/web/20150908201317/http://www.smalltalk.org/articles/article_20100320_a3_Getting_The_Message.html
>
> See also: "simple accessor and mutator methods" (1998)
> http://www.esug.org/data/Smalltalk/Historical/pocketst/whitepaper.html
>
> and: ST/X's asMutator (in protocol 'converting')
> https://live.exept.de/ClassDoc/classDocOf,CharacterArray
>
> So: what is the long term strategy here? After methods are deprecated and removed from the image, when those methods served the purpose of compatibility with 3rd party packages and other Smalltalks, is it expected that each outside package will either (a) maintain its own compatibility layer, like Grease, or (b) implement the removed methods via class extensions, thus possibly introducing conflicts?
>
> Thanks,
> Tim
>
>
>

marcel.taeumel

Re: Revisiting the deprecation of #asMutator vs #asSimpleSetter in 5.3 (sorry)

>Had I known the widespread understanding of #asMutator, I had objected more strongly against its removal -.-
Narf.

Well, there is also the idea of "convenience methods" ... #asMutator could be one of those. Not sure how this affects GraphQL. Chris?

Best,

Marcel

Am 05.01.2021 12:09:38 schrieb Tobias Pape <[hidden email]>:

Had I known the widespread understanding of #asMutator, I had objected more strongly against its removal -.-
Narf.

-t

> On 2. Jan 2021, at 19:44, Tim Johnson wrote:
>
> Hi,
>
> First, before the rest of this complain-y message:
>
> **Happy 2021 to everybody!**
>
> Now to shamefully bring up a closed matter: in 2019 there was some discussion on the mailing list that led to the deprecation of #asMutator. Some portions of the discussion can be seen here:
>
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201810.html
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201843.html
>
> Part of the argument was that "asMutator" and the notion of "mutators" was not seen elsewhere in the image, and that it conflicted with work someone was doing with GraphQL (?) which has its own notion of "mutators". Was there other rationale?
>
> In the meantime, various teams and projects will have to adapt their code. And, users have been coping with various packages not loading seamlessly in Squeak 5.3 due to this deprecation.
>
> Squot: https://github.com/hpi-swa/Squot/issues/266
> Seaside: https://github.com/SeasideSt/Seaside/issues/1195
> Also Seaside: https://github.com/SeasideSt/Seaside/search?q=asMutator
> HPI "Home Desktop System": http://wiki.squeak.org/squeak/2860
>
> I'm sorry for bringing up a settled matter, and for grandstanding a bit ("at what price progress?"), but: was #asMutator deprecated because of the argument that "mutators" are alien to Smalltalk and/or Squeak? If so, I (respectfully) have a hard time accepting part of that argument. A quick Google search turns up much literature.
>
> "To add an accessor method and a mutator method" (2015)
> https://medium.com/smalltalk-talk/getting-the-message-667d77ff78d
>
> ^ the above quotes & cites Alan Lovejoy's "Smalltalk: Getting The Message" (2007) https://web.archive.org/web/20150908201317/http://www.smalltalk.org/articles/article_20100320_a3_Getting_The_Message.html
>
> See also: "simple accessor and mutator methods" (1998)
> http://www.esug.org/data/Smalltalk/Historical/pocketst/whitepaper.html
>
> and: ST/X's asMutator (in protocol 'converting')
> https://live.exept.de/ClassDoc/classDocOf,CharacterArray
>
> So: what is the long term strategy here? After methods are deprecated and removed from the image, when those methods served the purpose of compatibility with 3rd party packages and other Smalltalks, is it expected that each outside package will either (a) maintain its own compatibility layer, like Grease, or (b) implement the removed methods via class extensions, thus possibly introducing conflicts?
>
> Thanks,
> Tim
>
>
>

Tobias Pape

Re: Revisiting the deprecation of #asMutator vs #asSimpleSetter in 5.3 (sorry)

> On 5. Jan 2021, at 12:10, Marcel Taeumel <[hidden email]> wrote:
>
> >Had I known the widespread understanding of #asMutator, I had objected more strongly against its removal -.-
> Narf.
>
> Well, there is also the idea of "convenience methods" ... #asMutator could be one of those.

Tim shows that it is essentially widespread, more than a convenience.
lets just put it back…

> Not sure how this affects GraphQL. Chris?
>
> Best,
> Marcel
>> Am 05.01.2021 12:09:38 schrieb Tobias Pape <[hidden email]>:
>>
>>
>> Had I known the widespread understanding of #asMutator, I had objected more strongly against its removal -.-
>> Narf.
>>
>> -t
>>
>> > On 2. Jan 2021, at 19:44, Tim Johnson wrote:
>> >
>> > Hi,
>> >
>> > First, before the rest of this complain-y message:
>> >
>> > **Happy 2021 to everybody!**
>> >
>> > Now to shamefully bring up a closed matter: in 2019 there was some discussion on the mailing list that led to the deprecation of #asMutator. Some portions of the discussion can be seen here:
>> >
>> > http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201810.html
>> > http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201843.html
>> >
>> > Part of the argument was that "asMutator" and the notion of "mutators" was not seen elsewhere in the image, and that it conflicted with work someone was doing with GraphQL (?) which has its own notion of "mutators". Was there other rationale?
>> >
>> > In the meantime, various teams and projects will have to adapt their code. And, users have been coping with various packages not loading seamlessly in Squeak 5.3 due to this deprecation.
>> >
>> > Squot: https://github.com/hpi-swa/Squot/issues/266
>> > Seaside: https://github.com/SeasideSt/Seaside/issues/1195
>> > Also Seaside: https://github.com/SeasideSt/Seaside/search?q=asMutator
>> > HPI "Home Desktop System": http://wiki.squeak.org/squeak/2860
>> >
>> > I'm sorry for bringing up a settled matter, and for grandstanding a bit ("at what price progress?"), but: was #asMutator deprecated because of the argument that "mutators" are alien to Smalltalk and/or Squeak? If so, I (respectfully) have a hard time accepting part of that argument. A quick Google search turns up much literature.
>> >
>> > "To add an accessor method and a mutator method" (2015)
>> > https://medium.com/smalltalk-talk/getting-the-message-667d77ff78d
>> >
>> > ^ the above quotes & cites Alan Lovejoy's "Smalltalk: Getting The Message" (2007) https://web.archive.org/web/20150908201317/http://www.smalltalk.org/articles/article_20100320_a3_Getting_The_Message.html
>> >
>> > See also: "simple accessor and mutator methods" (1998)
>> > http://www.esug.org/data/Smalltalk/Historical/pocketst/whitepaper.html
>> >
>> > and: ST/X's asMutator (in protocol 'converting')
>> > https://live.exept.de/ClassDoc/classDocOf,CharacterArray
>> >
>> > So: what is the long term strategy here? After methods are deprecated and removed from the image, when those methods served the purpose of compatibility with 3rd party packages and other Smalltalks, is it expected that each outside package will either (a) maintain its own compatibility layer, like Grease, or (b) implement the removed methods via class extensions, thus possibly introducing conflicts?
>> >
>> > Thanks,
>> > Tim
>> >
>> >
>> >
>>
>>
>>
>

marcel.taeumel

Re: Revisiting the deprecation of #asMutator vs #asSimpleSetter in 5.3 (sorry)

Hi Tobias.

> lets just put it back…

And adding a test that ensures that the Squeak image will not use it but #asSimpleSetter. Then would make it a "convenience" method. I would avoid supporting the mixed use. Biggest issue with #asMutator is that there is no #asSimpleGetter equivalent.

Best,

Marcel

Am 05.01.2021 12:13:08 schrieb Tobias Pape <[hidden email]>:

> On 5. Jan 2021, at 12:10, Marcel Taeumel wrote:
>
> >Had I known the widespread understanding of #asMutator, I had objected more strongly against its removal -.-
> Narf.
>
> Well, there is also the idea of "convenience methods" ... #asMutator could be one of those.

Tim shows that it is essentially widespread, more than a convenience.
lets just put it back…

> Not sure how this affects GraphQL. Chris?
>
> Best,
> Marcel
>> Am 05.01.2021 12:09:38 schrieb Tobias Pape :
>>
>>
>> Had I known the widespread understanding of #asMutator, I had objected more strongly against its removal -.-
>> Narf.
>>
>> -t
>>
>> > On 2. Jan 2021, at 19:44, Tim Johnson wrote:
>> >
>> > Hi,
>> >
>> > First, before the rest of this complain-y message:
>> >
>> > **Happy 2021 to everybody!**
>> >
>> > Now to shamefully bring up a closed matter: in 2019 there was some discussion on the mailing list that led to the deprecation of #asMutator. Some portions of the discussion can be seen here:
>> >
>> > http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201810.html
>> > http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201843.html
>> >
>> > Part of the argument was that "asMutator" and the notion of "mutators" was not seen elsewhere in the image, and that it conflicted with work someone was doing with GraphQL (?) which has its own notion of "mutators". Was there other rationale?
>> >
>> > In the meantime, various teams and projects will have to adapt their code. And, users have been coping with various packages not loading seamlessly in Squeak 5.3 due to this deprecation.
>> >
>> > Squot: https://github.com/hpi-swa/Squot/issues/266
>> > Seaside: https://github.com/SeasideSt/Seaside/issues/1195
>> > Also Seaside: https://github.com/SeasideSt/Seaside/search?q=asMutator
>> > HPI "Home Desktop System": http://wiki.squeak.org/squeak/2860
>> >
>> > I'm sorry for bringing up a settled matter, and for grandstanding a bit ("at what price progress?"), but: was #asMutator deprecated because of the argument that "mutators" are alien to Smalltalk and/or Squeak? If so, I (respectfully) have a hard time accepting part of that argument. A quick Google search turns up much literature.
>> >
>> > "To add an accessor method and a mutator method" (2015)
>> > https://medium.com/smalltalk-talk/getting-the-message-667d77ff78d
>> >
>> > ^ the above quotes & cites Alan Lovejoy's "Smalltalk: Getting The Message" (2007) https://web.archive.org/web/20150908201317/http://www.smalltalk.org/articles/article_20100320_a3_Getting_The_Message.html
>> >
>> > See also: "simple accessor and mutator methods" (1998)
>> > http://www.esug.org/data/Smalltalk/Historical/pocketst/whitepaper.html
>> >
>> > and: ST/X's asMutator (in protocol 'converting')
>> > https://live.exept.de/ClassDoc/classDocOf,CharacterArray
>> >
>> > So: what is the long term strategy here? After methods are deprecated and removed from the image, when those methods served the purpose of compatibility with 3rd party packages and other Smalltalks, is it expected that each outside package will either (a) maintain its own compatibility layer, like Grease, or (b) implement the removed methods via class extensions, thus possibly introducing conflicts?
>> >
>> > Thanks,
>> > Tim
>> >
>> >
>> >
>>
>>
>>
>

Tobias Pape

Re: Revisiting the deprecation of #asMutator vs #asSimpleSetter in 5.3 (sorry)

> On 5. Jan 2021, at 12:15, Marcel Taeumel <[hidden email]> wrote:
>
> Hi Tobias.
>
> > lets just put it back…
>
> And adding a test that ensures that the Squeak image will not use it but #asSimpleSetter. Then would make it a "convenience" method. I would avoid supporting the mixed use. Biggest issue with #asMutator is that there is no #asSimpleGetter equivalent.
>

so? not everything has to be two-ways xD

> Best,
> Marcel
>> Am 05.01.2021 12:13:08 schrieb Tobias Pape <[hidden email]>:
>>
>>
>>
>> > On 5. Jan 2021, at 12:10, Marcel Taeumel wrote:
>> >
>> > >Had I known the widespread understanding of #asMutator, I had objected more strongly against its removal -.-
>> > Narf.
>> >
>> > Well, there is also the idea of "convenience methods" ... #asMutator could be one of those.
>>
>> Tim shows that it is essentially widespread, more than a convenience.
>> lets just put it back…
>>
>> > Not sure how this affects GraphQL. Chris?
>> >
>> > Best,
>> > Marcel
>> >> Am 05.01.2021 12:09:38 schrieb Tobias Pape :
>> >>
>> >>
>> >> Had I known the widespread understanding of #asMutator, I had objected more strongly against its removal -.-
>> >> Narf.
>> >>
>> >> -t
>> >>
>> >> > On 2. Jan 2021, at 19:44, Tim Johnson wrote:
>> >> >
>> >> > Hi,
>> >> >
>> >> > First, before the rest of this complain-y message:
>> >> >
>> >> > **Happy 2021 to everybody!**
>> >> >
>> >> > Now to shamefully bring up a closed matter: in 2019 there was some discussion on the mailing list that led to the deprecation of #asMutator. Some portions of the discussion can be seen here:
>> >> >
>> >> > http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201810.html
>> >> > http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201843.html
>> >> >
>> >> > Part of the argument was that "asMutator" and the notion of "mutators" was not seen elsewhere in the image, and that it conflicted with work someone was doing with GraphQL (?) which has its own notion of "mutators". Was there other rationale?
>> >> >
>> >> > In the meantime, various teams and projects will have to adapt their code. And, users have been coping with various packages not loading seamlessly in Squeak 5.3 due to this deprecation.
>> >> >
>> >> > Squot: https://github.com/hpi-swa/Squot/issues/266
>> >> > Seaside: https://github.com/SeasideSt/Seaside/issues/1195
>> >> > Also Seaside: https://github.com/SeasideSt/Seaside/search?q=asMutator
>> >> > HPI "Home Desktop System": http://wiki.squeak.org/squeak/2860
>> >> >
>> >> > I'm sorry for bringing up a settled matter, and for grandstanding a bit ("at what price progress?"), but: was #asMutator deprecated because of the argument that "mutators" are alien to Smalltalk and/or Squeak? If so, I (respectfully) have a hard time accepting part of that argument. A quick Google search turns up much literature.
>> >> >
>> >> > "To add an accessor method and a mutator method" (2015)
>> >> > https://medium.com/smalltalk-talk/getting-the-message-667d77ff78d
>> >> >
>> >> > ^ the above quotes & cites Alan Lovejoy's "Smalltalk: Getting The Message" (2007) https://web.archive.org/web/20150908201317/http://www.smalltalk.org/articles/article_20100320_a3_Getting_The_Message.html
>> >> >
>> >> > See also: "simple accessor and mutator methods" (1998)
>> >> > http://www.esug.org/data/Smalltalk/Historical/pocketst/whitepaper.html
>> >> >
>> >> > and: ST/X's asMutator (in protocol 'converting')
>> >> > https://live.exept.de/ClassDoc/classDocOf,CharacterArray
>> >> >
>> >> > So: what is the long term strategy here? After methods are deprecated and removed from the image, when those methods served the purpose of compatibility with 3rd party packages and other Smalltalks, is it expected that each outside package will either (a) maintain its own compatibility layer, like Grease, or (b) implement the removed methods via class extensions, thus possibly introducing conflicts?
>> >> >
>> >> > Thanks,
>> >> > Tim
>> >> >
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >
>>
>>
>>
>

Eliot Miranda-2

Re: Revisiting the deprecation of #asMutator vs #asSimpleSetter in 5.3 (sorry)

In reply to this post by Tobias Pape

> On Jan 5, 2021, at 3:13 AM, Tobias Pape <[hidden email]> wrote:
>
>
>
>>> On 5. Jan 2021, at 12:10, Marcel Taeumel <[hidden email]> wrote:
>>>
>>> Had I known the widespread understanding of #asMutator, I had objected more strongly against its removal -.-
>> Narf.
>>
>> Well, there is also the idea of "convenience methods" ... #asMutator could be one of those.
>
> Tim shows that it is essentially widespread, more than a convenience.
> lets just put it back…

>
>> Not sure how this affects GraphQL. Chris?
>>
>> Best,
>> Marcel
>>> Am 05.01.2021 12:09:38 schrieb Tobias Pape <[hidden email]>:
>>>
>>>
>>> Had I known the widespread understanding of #asMutator, I had objected more strongly against its removal -.-
>>> Narf.
>>>
>>> -t
>>>
>>>> On 2. Jan 2021, at 19:44, Tim Johnson wrote:
>>>>
>>>> Hi,
>>>>
>>>> First, before the rest of this complain-y message:
>>>>
>>>> **Happy 2021 to everybody!**
>>>>
>>>> Now to shamefully bring up a closed matter: in 2019 there was some discussion on the mailing list that led to the deprecation of #asMutator. Some portions of the discussion can be seen here:
>>>>
>>>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201810.html
>>>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201843.html
>>>>
>>>> Part of the argument was that "asMutator" and the notion of "mutators" was not seen elsewhere in the image, and that it conflicted with work someone was doing with GraphQL (?) which has its own notion of "mutators". Was there other rationale?
>>>>
>>>> In the meantime, various teams and projects will have to adapt their code. And, users have been coping with various packages not loading seamlessly in Squeak 5.3 due to this deprecation.
>>>>
>>>> Squot: https://github.com/hpi-swa/Squot/issues/266
>>>> Seaside: https://github.com/SeasideSt/Seaside/issues/1195
>>>> Also Seaside: https://github.com/SeasideSt/Seaside/search?q=asMutator
>>>> HPI "Home Desktop System": http://wiki.squeak.org/squeak/2860
>>>>
>>>> I'm sorry for bringing up a settled matter, and for grandstanding a bit ("at what price progress?"), but: was #asMutator deprecated because of the argument that "mutators" are alien to Smalltalk and/or Squeak? If so, I (respectfully) have a hard time accepting part of that argument. A quick Google search turns up much literature.
>>>>
>>>> "To add an accessor method and a mutator method" (2015)
>>>> https://medium.com/smalltalk-talk/getting-the-message-667d77ff78d
>>>>
>>>> ^ the above quotes & cites Alan Lovejoy's "Smalltalk: Getting The Message" (2007) https://web.archive.org/web/20150908201317/http://www.smalltalk.org/articles/article_20100320_a3_Getting_The_Message.html
>>>>
>>>> See also: "simple accessor and mutator methods" (1998)
>>>> http://www.esug.org/data/Smalltalk/Historical/pocketst/whitepaper.html
>>>>
>>>> and: ST/X's asMutator (in protocol 'converting')
>>>> https://live.exept.de/ClassDoc/classDocOf,CharacterArray
>>>>
>>>> So: what is the long term strategy here? After methods are deprecated and removed from the image, when those methods served the purpose of compatibility with 3rd party packages and other Smalltalks, is it expected that each outside package will either (a) maintain its own compatibility layer, like Grease, or (b) implement the removed methods via class extensions, thus possibly introducing conflicts?
>>>>
>>>> Thanks,
>>>> Tim
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>

Chris Muller-3

Re: Revisiting the deprecation of #asMutator vs #asSimpleSetter in 5.3 (sorry)

In reply to this post by Tim Johnson-2

Hi Tim,

First, before the rest of this complain-y message:

**Happy 2021 to everybody!**

To you as well!

Now to shamefully bring up a closed matter: in 2019 there was some
discussion on the mailing list that led to the deprecation of #asMutator.
Some portions of the discussion can be seen here:

http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201810.html
http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201843.html

Part of the argument was that "asMutator" and the notion of "mutators" was
not seen elsewhere in the image, and that it conflicted with work someone
was doing with GraphQL (?) which has its own notion of "mutators". Was
there other rationale?

Yes, the conflict is in the design of the language of the system and its API. Smalltalkers have forever used the terms, "getters and setters," not "getters and mutators". GraphQL, OTOH, provides a first-class, formal definition of a "mutation".

(BTW, I never did announce the GraphQL engine, but it's on squeaksource, a solid and complete package).

In the meantime, various teams and projects will have to adapt their code.
And, users have been coping with various packages not loading seamlessly
in Squeak 5.3 due to this deprecation.

Squot: https://github.com/hpi-swa/Squot/issues/266
Seaside: https://github.com/SeasideSt/Seaside/issues/1195
Also Seaside: https://github.com/SeasideSt/Seaside/search?q=asMutator
HPI "Home Desktop System": http://wiki.squeak.org/squeak/2860

As mentioned in the original discussion, besides #isMutator being simply wrong in many cases (e.g., #at:, #indexOf:, etc.), this additional word feels application-specific. The systems above are all specific, external applications. I would recommend introducing the "mutator" lingo into Grease for Squeak and keep it out of the core library. We should stick with as minimal a set of words as possible. "Getters and setters," is the lingo. Otherwise, where does it end? Every word has several synonyms. It starts to get messy quickly.

I'm sorry for bringing up a settled matter, and for grandstanding a bit
("at what price progress?"), but: was #asMutator deprecated because of
the argument that "mutators" are alien to Smalltalk and/or Squeak? If so,
I (respectfully) have a hard time accepting part of that argument. A
quick Google search turns up much literature.

"To add an accessor method and a mutator method" (2015)
https://medium.com/smalltalk-talk/getting-the-message-667d77ff78d

^ the above quotes & cites Alan Lovejoy's "Smalltalk: Getting The Message"
(2007)
https://web.archive.org/web/20150908201317/http://www.smalltalk.org/articles/article_20100320_a3_Getting_The_Message.html

See also: "simple accessor and mutator methods" (1998)
http://www.esug.org/data/Smalltalk/Historical/pocketst/whitepaper.html

and: ST/X's asMutator (in protocol 'converting')
https://live.exept.de/ClassDoc/classDocOf,CharacterArray

These links and high-profile name look impressive until you follow them and look at their usage of "mutator" in context. As you pointed out, the first two of the four links refer to the same, single, idle usage in a single sentence. Not a "definition" of any sort. And the third is just the name of a one temporary variable. Pretty weak as an argument for inclusion.

That leaves just the last one, a more obscure Smalltalk, unrelated to Squeak? I'm not familiar with that project, but they might be interested in switching to the "getters and setters" linguistic.

So: what is the long term strategy here? After methods are deprecated
and removed from the image, when those methods served the purpose of
compatibility with 3rd party packages and other Smalltalks, is it expected
that each outside package will either (a) maintain its own compatibility
layer, like Grease, or (b) implement the removed methods via class
extensions, thus possibly introducing conflicts?

Yes. Both. The code must target a specific version of Squeak (to be reliable), so it can be easily done without package conflicts. Even real, unavoidable conflicts are not something to necessarily abhor -- it's usually due to flexing of Smalltalk muscles, being able to run with a modified system is one of its beautiful and powerful features.

- Chris

Chris Muller-3

Re: Revisiting the deprecation of #asMutator vs #asSimpleSetter in 5.3 (sorry)

In reply to this post by Tim Johnson-2

> #isMutator being simply wrong in many cases (e.g., #at:, #indexOf:, etc.), this additional word feels application-specific.

More than a "feeling," but that is actually the reason. You can't send #isMutator to any Symbol and get a meaningful answer in any general sense. Only in the context of some application-specific "code generator" or whatever -- where the code knows it's dealing with getters and setters -- that anyone could rely on it.

IOW, application-specific.

On Sat, Jan 2, 2021 at 12:44 PM Tim Johnson <[hidden email]> wrote:

Hi,

First, before the rest of this complain-y message:

**Happy 2021 to everybody!**

Now to shamefully bring up a closed matter: in 2019 there was some
discussion on the mailing list that led to the deprecation of #asMutator.
Some portions of the discussion can be seen here:

http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201810.html
http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201843.html

Part of the argument was that "asMutator" and the notion of "mutators" was
not seen elsewhere in the image, and that it conflicted with work someone
was doing with GraphQL (?) which has its own notion of "mutators". Was
there other rationale?

In the meantime, various teams and projects will have to adapt their code.
And, users have been coping with various packages not loading seamlessly
in Squeak 5.3 due to this deprecation.

Squot: https://github.com/hpi-swa/Squot/issues/266
Seaside: https://github.com/SeasideSt/Seaside/issues/1195
Also Seaside: https://github.com/SeasideSt/Seaside/search?q=asMutator
HPI "Home Desktop System": http://wiki.squeak.org/squeak/2860

I'm sorry for bringing up a settled matter, and for grandstanding a bit
("at what price progress?"), but: was #asMutator deprecated because of
the argument that "mutators" are alien to Smalltalk and/or Squeak? If so,
I (respectfully) have a hard time accepting part of that argument. A
quick Google search turns up much literature.

"To add an accessor method and a mutator method" (2015)
https://medium.com/smalltalk-talk/getting-the-message-667d77ff78d

^ the above quotes & cites Alan Lovejoy's "Smalltalk: Getting The Message"
(2007)
https://web.archive.org/web/20150908201317/http://www.smalltalk.org/articles/article_20100320_a3_Getting_The_Message.html

See also: "simple accessor and mutator methods" (1998)
http://www.esug.org/data/Smalltalk/Historical/pocketst/whitepaper.html

and: ST/X's asMutator (in protocol 'converting')
https://live.exept.de/ClassDoc/classDocOf,CharacterArray

So: what is the long term strategy here? After methods are deprecated
and removed from the image, when those methods served the purpose of
compatibility with 3rd party packages and other Smalltalks, is it expected
that each outside package will either (a) maintain its own compatibility
layer, like Grease, or (b) implement the removed methods via class
extensions, thus possibly introducing conflicts?

Thanks,
Tim

bpi

Re: Revisiting the deprecation of #asMutator vs #asSimpleSetter in 5.3 (sorry)

In reply to this post by Eliot Miranda-2

Dear Squeakers,

I have just been beaten by this when trying to run Seaside in a recent Squeak image.

While it should be possible to add it to Grease for Squeak that is non-trivial for me given Grease is not developed using Monticello anymore, but using Metacello in a metadataless Cypress repository. While it might be easy for the Seaside maintainers I don’t want to put an extra burden on them given they asked us for help maintaining Seaside for Squeak.

So I am strongly in favour of leaving it in Squeak, i.e. removing the deprecation. While I don’t disagree with the arguments for its deprecation, I value not breaking other people’s code more in this case.

Thank you for your consideration,
Bernhard

> Am 05.01.2021 um 18:01 schrieb Eliot Miranda <[hidden email]>:
>
>
>> On Jan 5, 2021, at 3:13 AM, Tobias Pape <[hidden email]> wrote:
>>
>>
>>>> On 5. Jan 2021, at 12:10, Marcel Taeumel <[hidden email]> wrote:
>>>>
>>>> Had I known the widespread understanding of #asMutator, I had objected more strongly against its removal -.-
>>> Narf.
>>>
>>> Well, there is also the idea of "convenience methods" ... #asMutator could be one of those.
>>
>> Tim shows that it is essentially widespread, more than a convenience.
>> lets just put it back…
>
> +1
>
>>
>>> Not sure how this affects GraphQL. Chris?
>>>
>>> Best,
>>> Marcel
>>>> Am 05.01.2021 12:09:38 schrieb Tobias Pape <[hidden email]>:
>>>>
>>>>
>>>> Had I known the widespread understanding of #asMutator, I had objected more strongly against its removal -.-
>>>> Narf.
>>>>
>>>> -t
>>>>
>>>>> On 2. Jan 2021, at 19:44, Tim Johnson wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> First, before the rest of this complain-y message:
>>>>>
>>>>> **Happy 2021 to everybody!**
>>>>>
>>>>> Now to shamefully bring up a closed matter: in 2019 there was some discussion on the mailing list that led to the deprecation of #asMutator. Some portions of the discussion can be seen here:
>>>>>
>>>>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201810.html
>>>>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201843.html
>>>>>
>>>>> Part of the argument was that "asMutator" and the notion of "mutators" was not seen elsewhere in the image, and that it conflicted with work someone was doing with GraphQL (?) which has its own notion of "mutators". Was there other rationale?
>>>>>
>>>>> In the meantime, various teams and projects will have to adapt their code. And, users have been coping with various packages not loading seamlessly in Squeak 5.3 due to this deprecation.
>>>>>
>>>>> Squot: https://github.com/hpi-swa/Squot/issues/266
>>>>> Seaside: https://github.com/SeasideSt/Seaside/issues/1195
>>>>> Also Seaside: https://github.com/SeasideSt/Seaside/search?q=asMutator
>>>>> HPI "Home Desktop System": http://wiki.squeak.org/squeak/2860
>>>>>
>>>>> I'm sorry for bringing up a settled matter, and for grandstanding a bit ("at what price progress?"), but: was #asMutator deprecated because of the argument that "mutators" are alien to Smalltalk and/or Squeak? If so, I (respectfully) have a hard time accepting part of that argument. A quick Google search turns up much literature.
>>>>>
>>>>> "To add an accessor method and a mutator method" (2015)
>>>>> https://medium.com/smalltalk-talk/getting-the-message-667d77ff78d
>>>>>
>>>>> ^ the above quotes & cites Alan Lovejoy's "Smalltalk: Getting The Message" (2007) https://web.archive.org/web/20150908201317/http://www.smalltalk.org/articles/article_20100320_a3_Getting_The_Message.html
>>>>>
>>>>> See also: "simple accessor and mutator methods" (1998)
>>>>> http://www.esug.org/data/Smalltalk/Historical/pocketst/whitepaper.html
>>>>>
>>>>> and: ST/X's asMutator (in protocol 'converting')
>>>>> https://live.exept.de/ClassDoc/classDocOf,CharacterArray
>>>>>
>>>>> So: what is the long term strategy here? After methods are deprecated and removed from the image, when those methods served the purpose of compatibility with 3rd party packages and other Smalltalks, is it expected that each outside package will either (a) maintain its own compatibility layer, like Grease, or (b) implement the removed methods via class extensions, thus possibly introducing conflicts?
>>>>>
>>>>> Thanks,
>>>>> Tim
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>

David T. Lewis

Re: Revisiting the deprecation of #asMutator vs #asSimpleSetter in 5.3 (sorry)

On Sun, Apr 11, 2021 at 12:44:08PM +0000, Bernhard Pieber wrote:

> Dear Squeakers,
>
> I have just been beaten by this when trying to run Seaside in a recent Squeak image.
>
> While it should be possible to add it to Grease for Squeak that is non-trivial for me given Grease is not developed using Monticello anymore, but using Metacello in a metadataless Cypress repository. While it might be easy for the Seaside maintainers I don???t want to put an extra burden on them given they asked us for help maintaining Seaside for Squeak.
>
> So I am strongly in favour of leaving it in Squeak, i.e. removing the deprecation. While I don???t disagree with the arguments for its deprecation, I value not breaking other people???s code more in this case.
>
> Thank you for your consideration,
> Bernhard
>

I have no opinion regarding the various selectors, but I do think that
is it important to support the people who do the work of maintaining
external packages, especially important packages like Seaside.

Letting asMutator be a synomym for asSimpleSetter along with a method
comment explaining why it still exists seems to work fine, see attached.
It passes the original SymbolTest>>tsetAsMutator (which is no longer in
the image) so I expect that it should work for Seaside also.

Dave

> > Am 05.01.2021 um 18:01 schrieb Eliot Miranda <[hidden email]>:
> >
> >
> >> On Jan 5, 2021, at 3:13 AM, Tobias Pape <[hidden email]> wrote:
> >> ???
> >>
> >>>> On 5. Jan 2021, at 12:10, Marcel Taeumel <[hidden email]> wrote:
> >>>>
> >>>> Had I known the widespread understanding of #asMutator, I had objected more strongly against its removal -.-
> >>> Narf.
> >>>
> >>> Well, there is also the idea of "convenience methods" ... #asMutator could be one of those.
> >>
> >> Tim shows that it is essentially widespread, more than a convenience.
> >> lets just put it back???
> >
> > +1
> >
> >>
> >>> Not sure how this affects GraphQL. Chris?
> >>>
> >>> Best,
> >>> Marcel
> >>>> Am 05.01.2021 12:09:38 schrieb Tobias Pape <[hidden email]>:
> >>>>
> >>>>
> >>>> Had I known the widespread understanding of #asMutator, I had objected more strongly against its removal -.-
> >>>> Narf.
> >>>>
> >>>> -t
> >>>>
> >>>>> On 2. Jan 2021, at 19:44, Tim Johnson wrote:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> First, before the rest of this complain-y message:
> >>>>>
> >>>>> **Happy 2021 to everybody!**
> >>>>>
> >>>>> Now to shamefully bring up a closed matter: in 2019 there was some discussion on the mailing list that led to the deprecation of #asMutator. Some portions of the discussion can be seen here:
> >>>>>
> >>>>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201810.html
> >>>>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201843.html
> >>>>>
> >>>>> Part of the argument was that "asMutator" and the notion of "mutators" was not seen elsewhere in the image, and that it conflicted with work someone was doing with GraphQL (?) which has its own notion of "mutators". Was there other rationale?
> >>>>>
> >>>>> In the meantime, various teams and projects will have to adapt their code. And, users have been coping with various packages not loading seamlessly in Squeak 5.3 due to this deprecation.
> >>>>>
> >>>>> Squot: https://github.com/hpi-swa/Squot/issues/266
> >>>>> Seaside: https://github.com/SeasideSt/Seaside/issues/1195
> >>>>> Also Seaside: https://github.com/SeasideSt/Seaside/search?q=asMutator
> >>>>> HPI "Home Desktop System": http://wiki.squeak.org/squeak/2860
> >>>>>
> >>>>> I'm sorry for bringing up a settled matter, and for grandstanding a bit ("at what price progress?"), but: was #asMutator deprecated because of the argument that "mutators" are alien to Smalltalk and/or Squeak? If so, I (respectfully) have a hard time accepting part of that argument. A quick Google search turns up much literature.
> >>>>>
> >>>>> "To add an accessor method and a mutator method" (2015)
> >>>>> https://medium.com/smalltalk-talk/getting-the-message-667d77ff78d
> >>>>>
> >>>>> ^ the above quotes & cites Alan Lovejoy's "Smalltalk: Getting The Message" (2007) https://web.archive.org/web/20150908201317/http://www.smalltalk.org/articles/article_20100320_a3_Getting_The_Message.html
> >>>>>
> >>>>> See also: "simple accessor and mutator methods" (1998)
> >>>>> http://www.esug.org/data/Smalltalk/Historical/pocketst/whitepaper.html
> >>>>>
> >>>>> and: ST/X's asMutator (in protocol 'converting')
> >>>>> https://live.exept.de/ClassDoc/classDocOf,CharacterArray
> >>>>>
> >>>>> So: what is the long term strategy here? After methods are deprecated and removed from the image, when those methods served the purpose of compatibility with 3rd party packages and other Smalltalks, is it expected that each outside package will either (a) maintain its own compatibility layer, like Grease, or (b) implement the removed methods via class extensions, thus possibly introducing conflicts?
> >>>>>
> >>>>> Thanks,
> >>>>> Tim
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >>
> >
>
>
>

Symbol-asMutator.st (283 bytes) Download Attachment

Nicolas Cellier

Re: Revisiting the deprecation of #asMutator vs #asSimpleSetter in 5.3 (sorry)

Hi all,
it seems we have enough +1, let's just do it.

Le dim. 11 avr. 2021 à 16:45, David T. Lewis <[hidden email]> a écrit :

>
> On Sun, Apr 11, 2021 at 12:44:08PM +0000, Bernhard Pieber wrote:
> > Dear Squeakers,
> >
> > I have just been beaten by this when trying to run Seaside in a recent Squeak image.
> >
> > While it should be possible to add it to Grease for Squeak that is non-trivial for me given Grease is not developed using Monticello anymore, but using Metacello in a metadataless Cypress repository. While it might be easy for the Seaside maintainers I don???t want to put an extra burden on them given they asked us for help maintaining Seaside for Squeak.
> >
> > So I am strongly in favour of leaving it in Squeak, i.e. removing the deprecation. While I don???t disagree with the arguments for its deprecation, I value not breaking other people???s code more in this case.
> >
> > Thank you for your consideration,
> > Bernhard
> >
>
> I have no opinion regarding the various selectors, but I do think that
> is it important to support the people who do the work of maintaining
> external packages, especially important packages like Seaside.
>
> Letting asMutator be a synomym for asSimpleSetter along with a method
> comment explaining why it still exists seems to work fine, see attached.
> It passes the original SymbolTest>>tsetAsMutator (which is no longer in
> the image) so I expect that it should work for Seaside also.
>
> Dave
>
>
> > > Am 05.01.2021 um 18:01 schrieb Eliot Miranda <[hidden email]>:
> > >
> > >
> > >> On Jan 5, 2021, at 3:13 AM, Tobias Pape <[hidden email]> wrote:
> > >> ???
> > >>
> > >>>> On 5. Jan 2021, at 12:10, Marcel Taeumel <[hidden email]> wrote:
> > >>>>
> > >>>> Had I known the widespread understanding of #asMutator, I had objected more strongly against its removal -.-
> > >>> Narf.
> > >>>
> > >>> Well, there is also the idea of "convenience methods" ... #asMutator could be one of those.
> > >>
> > >> Tim shows that it is essentially widespread, more than a convenience.
> > >> lets just put it back???
> > >
> > > +1
> > >
> > >>
> > >>> Not sure how this affects GraphQL. Chris?
> > >>>
> > >>> Best,
> > >>> Marcel
> > >>>> Am 05.01.2021 12:09:38 schrieb Tobias Pape <[hidden email]>:
> > >>>>
> > >>>>
> > >>>> Had I known the widespread understanding of #asMutator, I had objected more strongly against its removal -.-
> > >>>> Narf.
> > >>>>
> > >>>> -t
> > >>>>
> > >>>>> On 2. Jan 2021, at 19:44, Tim Johnson wrote:
> > >>>>>
> > >>>>> Hi,
> > >>>>>
> > >>>>> First, before the rest of this complain-y message:
> > >>>>>
> > >>>>> **Happy 2021 to everybody!**
> > >>>>>
> > >>>>> Now to shamefully bring up a closed matter: in 2019 there was some discussion on the mailing list that led to the deprecation of #asMutator. Some portions of the discussion can be seen here:
> > >>>>>
> > >>>>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201810.html
> > >>>>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201843.html
> > >>>>>
> > >>>>> Part of the argument was that "asMutator" and the notion of "mutators" was not seen elsewhere in the image, and that it conflicted with work someone was doing with GraphQL (?) which has its own notion of "mutators". Was there other rationale?
> > >>>>>
> > >>>>> In the meantime, various teams and projects will have to adapt their code. And, users have been coping with various packages not loading seamlessly in Squeak 5.3 due to this deprecation.
> > >>>>>
> > >>>>> Squot: https://github.com/hpi-swa/Squot/issues/266
> > >>>>> Seaside: https://github.com/SeasideSt/Seaside/issues/1195
> > >>>>> Also Seaside: https://github.com/SeasideSt/Seaside/search?q=asMutator
> > >>>>> HPI "Home Desktop System": http://wiki.squeak.org/squeak/2860
> > >>>>>
> > >>>>> I'm sorry for bringing up a settled matter, and for grandstanding a bit ("at what price progress?"), but: was #asMutator deprecated because of the argument that "mutators" are alien to Smalltalk and/or Squeak? If so, I (respectfully) have a hard time accepting part of that argument. A quick Google search turns up much literature.
> > >>>>>
> > >>>>> "To add an accessor method and a mutator method" (2015)
> > >>>>> https://medium.com/smalltalk-talk/getting-the-message-667d77ff78d
> > >>>>>
> > >>>>> ^ the above quotes & cites Alan Lovejoy's "Smalltalk: Getting The Message" (2007) https://web.archive.org/web/20150908201317/http://www.smalltalk.org/articles/article_20100320_a3_Getting_The_Message.html
> > >>>>>
> > >>>>> See also: "simple accessor and mutator methods" (1998)
> > >>>>> http://www.esug.org/data/Smalltalk/Historical/pocketst/whitepaper.html
> > >>>>>
> > >>>>> and: ST/X's asMutator (in protocol 'converting')
> > >>>>> https://live.exept.de/ClassDoc/classDocOf,CharacterArray
> > >>>>>
> > >>>>> So: what is the long term strategy here? After methods are deprecated and removed from the image, when those methods served the purpose of compatibility with 3rd party packages and other Smalltalks, is it expected that each outside package will either (a) maintain its own compatibility layer, like Grease, or (b) implement the removed methods via class extensions, thus possibly introducing conflicts?
> > >>>>>
> > >>>>> Thanks,
> > >>>>> Tim
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>
> > >>
> > >>
> > >>
> > >
> >
> >
> >
>

David T. Lewis

Re: Revisiting the deprecation of #asMutator vs #asSimpleSetter in 5.3 (sorry)

On Sun, Apr 11, 2021 at 05:01:31PM +0200, Nicolas Cellier wrote:
> Hi all,
> it seems we have enough +1, let's just do it.
>

Done.

bpi

Re: Revisiting the deprecation of #asMutator vs #asSimpleSetter in 5.3 (sorry)

Thank you, David!

Bernhard

> Am 12.04.2021 um 04:11 schrieb David T. Lewis <[hidden email]>:
>
>
> On Sun, Apr 11, 2021 at 05:01:31PM +0200, Nicolas Cellier wrote:
>> Hi all,
>> it seems we have enough +1, let's just do it.
>>
>
> Done.

marcel.taeumel

Re: Revisiting the deprecation of #asMutator vs #asSimpleSetter in 5.3 (sorry)

Hi Dave.

Thanks. Maybe also add a pointer to the discussion on this list.

Best,

Marcel

Am 12.04.2021 08:11:29 schrieb Bernhard Pieber <[hidden email]>:
Thank you, David!

Bernhard

> Am 12.04.2021 um 04:11 schrieb David T. Lewis :
>
>
> On Sun, Apr 11, 2021 at 05:01:31PM +0200, Nicolas Cellier wrote:
>> Hi all,
>> it seems we have enough +1, let's just do it.
>>
>
> Done.

David T. Lewis

Re: Revisiting the deprecation of #asMutator vs #asSimpleSetter in 5.3 (sorry)

On Mon, Apr 12, 2021 at 08:43:45AM +0200, Marcel Taeumel wrote:

>
> > Am 12.04.2021 um 04:11 schrieb David T. Lewis :
> >
> >
> > On Sun, Apr 11, 2021 at 05:01:31PM +0200, Nicolas Cellier wrote:
> >> Hi all,
> >> it seems we have enough +1, let's just do it.
> >>
> >
> > Done.
>
> Hi Dave.
>
> Thanks. Maybe also add a pointer to the discussion on this list.
>

Hi Marcel,

Yes, I should have added a link to the discussion. I could save a
fixed System-dtl.1225 to trunk, although I am afraid it may cause
problems for the update stream for people who have already loaded
that version number with a different UUID in their trunk update.

If someone can confirm that it is safe to replace the existing
System-dtl.1225 with another one that differs only by commit comment
and UUID, then I'll copy it up to trunk. Otherwise I think I'll
play it safe and leave it alone.

Thanks,
Dave

Christoph Thiede

Re: Revisiting the deprecation of #asMutator vs #asSimpleSetter in 5.3 (sorry)

Maybe just create a new version and add the pointer directly into the comment of #asMutator? This will be even more helpful for people who wonder "Should I use #asMutator or #asSimpleSetter"?

I also wonder whether #asMutator deserves a #deprecate flag at least. Otherwise, we will have the situation of two ambiguous selectors without any recommendation, again.

Best,

Christoph

Von: Squeak-dev <[hidden email]> im Auftrag von David T. Lewis <[hidden email]>
Gesendet: Montag, 12. April 2021 22:56:10
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Revisiting the deprecation of #asMutator vs #asSimpleSetter in 5.3 (sorry)

On Mon, Apr 12, 2021 at 08:43:45AM +0200, Marcel Taeumel wrote:
>
> > Am 12.04.2021 um 04:11 schrieb David T. Lewis :
> >
> >
> > On Sun, Apr 11, 2021 at 05:01:31PM +0200, Nicolas Cellier wrote:
> >> Hi all,
> >> it seems we have enough +1, let's just do it.
> >>
> >
> > Done.
>
> Hi Dave.
>
> Thanks. Maybe also add a pointer to the discussion on this list.
>

Hi Marcel,

Yes, I should have added a link to the discussion. I could save a
fixed System-dtl.1225 to trunk, although I am afraid it may cause
problems for the update stream for people who have already loaded
that version number with a different UUID in their trunk update.

If someone can confirm that it is safe to replace the existing
System-dtl.1225 with another one that differs only by commit comment
and UUID, then I'll copy it up to trunk. Otherwise I think I'll
play it safe and leave it alone.

Thanks,
Dave

Carpe Squeak!

David T. Lewis

Re: Revisiting the deprecation of #asMutator vs #asSimpleSetter in 5.3 (sorry)

On Mon, Apr 12, 2021 at 09:11:54PM +0000, Thiede, Christoph wrote:
> Maybe just create a new version and add the pointer directly into the
> comment of #asMutator? This will be even more helpful for people who
> wonder "Should I use #asMutator or #asSimpleSetter"?
>
> I also wonder whether #asMutator deserves a #deprecate flag at least.
> Otherwise, we will have the situation of two ambiguous selectors without
> any recommendation, again.
>

Let's not over-engineer it. Just look at the method comment. Is anyone
ever going to use a method with a name like "asMutator" without first
looking at the method to see what it does? I certainly hope not :-)

Symbol>>asMutator
"Synonym for asSimpleSetter, retained for support of external packages such as Seaside"
^ self asSimpleSetter

Dave

Chris Muller-3

Re: Revisiting the deprecation of #asMutator vs #asSimpleSetter in 5.3 (sorry)

Another option is to use "browse revisions", then select the revision which un-deprecates it and select, "browse origin". Then you will have the version name which can be searched on the list. :)

On Mon, Apr 12, 2021 at 9:10 PM David T. Lewis <[hidden email]> wrote:

On Mon, Apr 12, 2021 at 09:11:54PM +0000, Thiede, Christoph wrote:
> Maybe just create a new version and add the pointer directly into the
> comment of #asMutator? This will be even more helpful for people who
> wonder "Should I use #asMutator or #asSimpleSetter"?
>
> I also wonder whether #asMutator deserves a #deprecate flag at least.
> Otherwise, we will have the situation of two ambiguous selectors without
> any recommendation, again.
>

Let's not over-engineer it. Just look at the method comment. Is anyone
ever going to use a method with a name like "asMutator" without first
looking at the method to see what it does? I certainly hope not :-)

Symbol>>asMutator
"Synonym for asSimpleSetter, retained for support of external packages such as Seaside"
^ self asSimpleSetter

Dave