[squeak-dev] Revisiting the deprecation of #asMutator vs #asSimpleSetter in 5.3 (sorry)

Bernhard Pieber bernhard at pieber.com
Sun Apr 11 12:44:08 UTC 2021


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 at gmail.com>:
>
>
>> On Jan 5, 2021, at 3:13 AM, Tobias Pape <Das.Linux at gmx.de> wrote:
>> 
>>
>>>> On 5. Jan 2021, at 12:10, Marcel Taeumel <marcel.taeumel at 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 at 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.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
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>




More information about the Squeak-dev mailing list