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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Tim Johnson-2
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



Reply | Threaded
Open this post in threaded view
|

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

marcel.taeumel
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





Reply | Threaded
Open this post in threaded view
|

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

Tobias Pape
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
>
>
>



Reply | Threaded
Open this post in threaded view
|

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

marcel.taeumel
>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
>
>
>





Reply | Threaded
Open this post in threaded view
|

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

Tobias Pape


> 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
>> >
>> >
>> >
>>
>>
>>
>



Reply | Threaded
Open this post in threaded view
|

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

marcel.taeumel
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
>> >
>> >
>> >
>>
>>
>>
>





Reply | Threaded
Open this post in threaded view
|

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

Tobias Pape


> 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
>> >> >
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >
>>
>>
>>
>



Reply | Threaded
Open this post in threaded view
|

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

Eliot Miranda-2
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…

+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
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>

Reply | Threaded
Open this post in threaded view
|

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

Chris Muller-3
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


Reply | Threaded
Open this post in threaded view
|

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

Chris Muller-3
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