My thoughts on setters are these:

- If we have setters without getters, it should probably just be a method, because otherwise we aren't behaving like an attribute.

- (Getters without setters are fine if we want a value to be read-only and feel the need to enforce that.)

- I am generally weary of setters where they are hiding magic, especially costly magic due to non-obvious side-effects.  (This case is not costly magic.)  Even sometimes when it seems like it should be obvious to people that there must be some kind of setter magic going on, in Thunderbird people totally missed the cues.  (Sometimes because they were just copying and pasting code with minimal investigation.)

- Setters seem like a reasonable way to implement representation invariant enforcement without getting all Java setFoo/getFoo.  However, if there's a deeper semantics going on, I think I'd favor a method, see next:

My personal preference is that when there are side-effects to try and codify the side-effects in the name of the function, especially if it lets us avoid needing to have a comment above the line.  For example, if I was reviewing code that set 'messageReader' I would probably want a line above it saying "// Binds reader events and moves cursor to the displayed message in the reader".  A method like bindMessageReaderAndUpdatePosition() arguably reduces the need for an explicit comment or for the user of the code to lookup the contents of the method to see what it does.