The WriteBarrier class-comment states:
- any methods that potentially modify instance variables will be overriden in this new class. The overridden method stores the original values of the instance variable in temps, then calls the super method, and then compares the current inst var values with the originals. - If the instance variable values have changed, the WriteBarrier will be notified with a send to #modified:, with the object that was modified as the single argument. - For variably-sized classes, #at:put: is also overridden to provide the same notification.
While integrating WriteBarrier into Magma, I noticed my Array test was actually slower than without WriteBarrier. The problem is in WBClassBuilder>>installAtPutOverrides, which do not check whether the value is changed, it signals #modified no matter what.
To demonstrate this:
| 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.
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?
Regards, Chris
Thank you for your report. I have transferred your report to Squeak's Mantis Database and you can followup on the issue if desired by going to http://bugs.impara.de/view.php?id=1020 .
In the future please report new issues on Squeak's Mantis Database at http://bugs.impara.de/ .
Thanks!
Ken
On Mar 29, 2005 9:56 PM, Chris Muller chris@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
squeak-dev@lists.squeakfoundation.org