[BUG][FIX] WriteBarrier at:put: fix for variable classes
Avi Bryant
avi.bryant at gmail.com
Sat Apr 2 23:32:19 UTC 2005
On Mar 29, 2005 9:56 PM, Chris Muller <chris at funkyobjects.org> wrote:
> | a wb |
> a _ Array with: true.
> wb _ DirtySetWriteBarrier new.
> wb add: a.
> a at: 1 put: true.
> wb dirtySet includes: a
>
> This script should return false. After loading the attached fix, it will.
Thanks; I've incorporated both your test and your fix, and released a
new version to SM.
> Also, I have a question. Are there any caveats to overriding instVarAt:put: to
> check for a new value as well? The same class-comment says:
>
> - The WriteBarrier is semi-permeable: if you want to modify an object directly
> without triggering notifications, you can use #instVarAt:put: and
> #basicAt:put:.
>
> This reduces transparency albeit just a little; and this same permeability
> could be achieved by temporarily removing from the WriteBarrier. Is there any
> reason not to do it?
I honestly can't remember if there was a particular reason or not.
Right now, it seems to me like a matter of taste: how much
transparency, and how much permeability, do we actually want?
Is there a particular usage of #instVarAt:put: that you're thinking of
that you'd like to have caught?
Avi
More information about the Squeak-dev
mailing list
|