[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