[squeak-dev] Bug in Environment>>#removeKey:ifAbsent:

tim Rowledge tim at rowledge.org
Wed Sep 1 20:24:56 UTC 2021

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 Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Strange OpCodes: JUM: Jeer at User's Mistake

More information about the Squeak-dev mailing list