Alright. Please see Environments-ct.83 and Tests-ct.465, currently both located in the inbox. :-)<br>
<br>
Best,<br>
Christoph<br>
<br>
<font color="#808080">---<br>
</font><i><font color="#808080">Sent from </font></i><i><u><a href="https://github.com/hpi-swa-lab/squeak-inbox-talk"><font color="#808080">Squeak Inbox Talk</font></a></u></i><br>
<br>
On 2021-09-01T13:24:56-07:00, tim@rowledge.org wrote:<br>
<br>
> 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<br>
> <br>
> > On 2021-09-01, at 1:03 PM, Jakob Reschke <jakres+squeak at gmail.com> wrote:<br>
> > <br>
> > Hi Christoph,<br>
> > <br>
> > At which comments did you look? The comments in the remove methods in<br>
> > Environment do not state that the previous value were returned. They<br>
> > do not say anything about the answer to the message.<br>
> > <br>
> > Notwithstanding that I, too, would find it more intuitive if this<br>
> > worked similar to the Dictionary protocol and did in fact return the<br>
> > previous value. Practically I doubt that if you remove a name from a<br>
> > namespace you should have a use for the last value.<br>
> > <br>
> > The binding is overwritten in Environment>>#undeclare:from: by the<br>
> > becomeForward. It redirects everything that used the existing binding<br>
> > to the new undeclared binding, which has the value nil. (That is<br>
> > good.) So to "fix" the behavior of removeKey: one has to get the value<br>
> > of the binding before running the policies. The undeclare:from: is<br>
> > sent from Environment>>#hideBinding:, which is used in all the import<br>
> > policies, including importSelf.<br>
> > <br>
> > Kind regards,<br>
> > Jakob<br>
> > <br>
> > Am So., 29. Aug. 2021 um 01:32 Uhr schrieb<br>
> > <christoph.thiede at student.hpi.uni-potsdam.de>:<br>
> >> <br>
> >> Hi all,<br>
> >> <br>
> >> I just stumbled upon the following behavior:<br>
> >> <br>
> >> Smalltalk globals at: #MyTempVar put: 42.<br>
> >> Smalltalk globals removeKey: #MyTempVar. "--> nil"<br>
> >> <br>
> >> 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?<br>
> >> <br>
> >> Best,<br>
> >> Christoph<br>
> >> <br>
> >> ---<br>
> >> Sent from Squeak Inbox Talk<br>
> > <br>
> > <br>
> <br>
> <br>
> tim<br>
> --<br>
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim<br>
> Strange OpCodes: JUM: Jeer at User's Mistake<br>
> <br>
>