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.htm... http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201843.htm...
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...
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
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 digit@sonic.net: 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.htm... http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201843.htm...
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...
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
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 digit@sonic.net 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.htm... http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201843.htm...
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...
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
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 das.linux@gmx.de:
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.htm... http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201843.htm...
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...
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
On 5. Jan 2021, at 12:10, Marcel Taeumel marcel.taeumel@hpi.de 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 das.linux@gmx.de:
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.htm... http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201843.htm...
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...
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
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 das.linux@gmx.de:
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.htm... http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201843.htm...
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...
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
On 5. Jan 2021, at 12:15, Marcel Taeumel marcel.taeumel@hpi.de 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 das.linux@gmx.de:
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.htm... http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201843.htm...
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...
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
On Jan 5, 2021, at 3:13 AM, Tobias Pape Das.Linux@gmx.de wrote:
On 5. Jan 2021, at 12:10, Marcel Taeumel marcel.taeumel@hpi.de 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 das.linux@gmx.de:
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.htm... http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201843.htm...
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...
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
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 eliot.miranda@gmail.com:
On Jan 5, 2021, at 3:13 AM, Tobias Pape Das.Linux@gmx.de wrote:
On 5. Jan 2021, at 12:10, Marcel Taeumel marcel.taeumel@hpi.de 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 das.linux@gmx.de:
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.htm... http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201843.htm...
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...
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
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 eliot.miranda@gmail.com:
On Jan 5, 2021, at 3:13 AM, Tobias Pape Das.Linux@gmx.de wrote: ???
On 5. Jan 2021, at 12:10, Marcel Taeumel marcel.taeumel@hpi.de 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 das.linux@gmx.de:
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.htm... http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201843.htm...
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...
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
Hi all, it seems we have enough +1, let's just do it.
Le dim. 11 avr. 2021 à 16:45, David T. Lewis lewis@mail.msen.com 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 eliot.miranda@gmail.com:
On Jan 5, 2021, at 3:13 AM, Tobias Pape Das.Linux@gmx.de wrote: ???
On 5. Jan 2021, at 12:10, Marcel Taeumel marcel.taeumel@hpi.de 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 das.linux@gmx.de:
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.htm... > http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201843.htm... > > 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... > > 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 > > >
Thank you, David!
Bernhard
Am 12.04.2021 um 04:11 schrieb David T. Lewis lewis@mail.msen.com:
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.
Best, Marcel Am 12.04.2021 08:11:29 schrieb Bernhard Pieber bernhard@pieber.com: 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.
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
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 squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von David T. Lewis lewis@mail.msen.com 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
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
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 lewis@mail.msen.com 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
Hi Chris!
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. :)
Works like a charm. :-) Would be nice if you somehow show the repository description in the revisions browser. Then, users could inspect the list of repositories if some issue occurs.
Best, Marcel Am 13.04.2021 07:22:45 schrieb Chris Muller asqueaker@gmail.com: 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 <lewis@mail.msen.com [mailto:lewis@mail.msen.com]> 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
Hi Dave,
you could just add another version. No need to modify dtl.1225 :-)
Best, Marcel Am 12.04.2021 22:56:16 schrieb David T. Lewis lewis@mail.msen.com: 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
On Wed, Apr 14, 2021 at 10:30:24AM +0200, Marcel Taeumel wrote:
Hi Dave,
you could just add another version. No need to modify dtl.1225 :-)
Sorry, too late to do that now. But in case future readers of this list archive are interested, the discussion on squeak-dev is here:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2021-April/214699.htm...
The motivating issue for Seaside is:
https://github.com/SeasideSt/Seaside/issues/1195
Dave
Best, Marcel Am 12.04.2021 22:56:16 schrieb David T. Lewis lewis@mail.msen.com: 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
On Wed, Apr 14, 2021 at 10:31:28PM -0400, David T. Lewis wrote:
On Wed, Apr 14, 2021 at 10:30:24AM +0200, Marcel Taeumel wrote:
Hi Dave,
you could just add another version. No need to modify dtl.1225 :-)
Sorry, too late to do that now. But in case future readers of this list archive are interested, the discussion on squeak-dev is here:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2021-April/214699.htm...
The motivating issue for Seaside is:
https://github.com/SeasideSt/Seaside/issues/1195
Dave
But of course adding this information to the current mail thread is completely pointless, d'oh!
So I also added it to the "squeak-dev] The Trunk: System-dtl.1225.mcz" thread to give people a better chance of finding it in the future.
Again, sorry for not putting this in the original commit message.
Dave
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.htm...
http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201843.htm...
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...
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
#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 digit@sonic.net 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.htm...
http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201843.htm...
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...
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
squeak-dev@lists.squeakfoundation.org
-
Bernhard Pieber -
Chris Muller -
David T. Lewis -
Eliot Miranda -
Marcel Taeumel -
Nicolas Cellier -
Thiede, Christoph -
Tim Johnson -
Tobias Pape