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 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
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >>
> >
> 
> 
> 
-------------- next part --------------
'From Squeak6.0alpha of 3 April 2021 [latest update: #20329] on 11 April 2021 at 10:23:26 am'!!Symbol methodsFor: '*System-Support' stamp: 'dtl 4/11/2021 09:26'!asMutator	"Synonym for asSimpleSetter, retained for support of external packages such as Seaside"	^ self asSimpleSetter! !