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

Jakob Reschke jakres+squeak at gmail.com
Wed Sep 1 20:03:51 UTC 2021

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,

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

More information about the Squeak-dev mailing list