Alright. Please see Environments-ct.83 and Tests-ct.465, currently both located in the inbox. :-)

Best,
Christoph

---
Sent from Squeak Inbox Talk

On 2021-09-01T13:24:56-07:00, tim at rowledge.org wrote:

> The convention as I recall it has always been that we return the object added with #add: or #at:put: type messages, and the object removed with #remove: or #removeAt: type messages
> 
> > On 2021-09-01, at 1:03 PM, Jakob Reschke <jakres+squeak at gmail.com> wrote:
> > 
> > Hi Christoph,
> > 
> > At which comments did you look? The comments in the remove methods in
> > Environment do not state that the previous value were returned. They
> > do not say anything about the answer to the message.
> > 
> > Notwithstanding that I, too, would find it more intuitive if this
> > worked similar to the Dictionary protocol and did in fact return the
> > previous value. Practically I doubt that if you remove a name from a
> > namespace you should have a use for the last value.
> > 
> > The binding is overwritten in Environment>>#undeclare:from: by the
> > becomeForward. It redirects everything that used the existing binding
> > to the new undeclared binding, which has the value nil. (That is
> > good.) So to "fix" the behavior of removeKey: one has to get the value
> > of the binding before running the policies. The undeclare:from: is
> > sent from Environment>>#hideBinding:, which is used in all the import
> > policies, including importSelf.
> > 
> > Kind regards,
> > Jakob
> > 
> > Am So., 29. Aug. 2021 um 01:32 Uhr schrieb
> > <christoph.thiede at student.hpi.uni-potsdam.de>:
> >> 
> >> Hi all,
> >> 
> >> I just stumbled upon the following behavior:
> >> 
> >> Smalltalk globals at: #MyTempVar put: 42.
> >> Smalltalk globals removeKey: #MyTempVar. "--> nil"
> >> 
> >> This confuses me, according to the method comment, I would have expected #removeKey: to answer the previously stored value instead, but somehow some binding policy appears to reset the value during removal. Is this a bug, or should we change the comment? Or should we just evaluate the binding prior to noticing the removal?
> >> 
> >> Best,
> >> Christoph
> >> 
> >> ---
> >> Sent from Squeak Inbox Talk
> > 
> > 
> 
> 
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Strange OpCodes: JUM: Jeer at User's Mistake
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210918/9fcf3859/attachment.html>