Comment #4 on issue 4623 by
[hidden email]: do not mutate instance
variable
http://code.google.com/p/pharo/issues/detail?id=4623Of course, the bug report is poorly written,
- no reference to the original post in mailing list,
- a few lines copied but difficult to understand without context,
- a long debug log aggregating many errors...
Maybe closing such report is the right policy...
My micro contribution will be to give enough elements to make the decision
more based on bug contents than on bug container ;)
The reference message is in this thread:
http://lists.gforge.inria.fr/pipermail/pharo-project/2011-August/052203.htmlOne of the errors in debug log is:
--- The full stack ---
Array(Object)>>doesNotUnderstand: #nextPut:
[enteredMorphs nextPut: aMorph] in MouseOverHandler>>noticeMouseOver:event:
IdentitySet(Set)>>remove:ifAbsent:
MouseOverHandler>>noticeMouseOver:event:
So, noticeMouseOver:event: expected a WriteStream but found an Array.
Array and WriteStream are poorly polymorphic, so you can't replace one with
another.
One source of the problem is that the inst var suddenly points to another
class (what I called mutation) :
enteredMorphs := enteredMorphs contents.
Some methods expect enteredMorphs to contain a WriteStream.
Some methods expect enteredMorphs to contain an Array.
This kind of tricks makes the code harder to understand...
... and mostly impossible to reuse, refine (subclass) or modify.
Further in the thread, I said:
"Squeak already broke the enteredMorph ivar, but reset it at the end of
the method with a
self initializeTrackedMorphs
OK, some clean up was required, but you see, you can make things worse
when cleaning...
It's like Pharo cleaning removed the antidote, but forgot to remove
the poison..."
The code was modified and broken in Pharo 1.3, so above trap worked
perfectly ;)
But Pharo is moving fast.
The questions that you must now answer are:
1) was the anti-mutation restored? (ugly workaround of squeak restored)
2) or was the mutation removed? (thanks for future generations of UI
programmers)
3) or was the whole class rewritten? (many thanks !!!)
If you don't answer yes to 2) or 3), then one issue should remain open.
Good luck to track modifications with current state of our dev tools (this
tracker and Monticello).
_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker
Locked
