Opened 9 years ago
Last modified 9 years ago
#54 new todo
Better support for instvar modification breakpoints
Reported by: | Jan Vrany | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | |
Component: | default | Keywords: | |
Cc: | Also affects CVS HEAD (eXept version): | no |
Description
Actually, I found modification trap not very useful because it triggers break after all method's code is executed, so you dont really know where the instvar was modified. If it is modified in two branches, you don't know which one did it.
It's even worse when there are blocks involved - at the time of breakpoint the most interesting part of the stack is gone. If the method modifies the instvar in a block that outlives the method, you don't get breakpoint at all.
Instead of generating anonymous subclass, it should instead instrument methods and inject guarding code before each assignment.
Implementation-wise I think it's even simpler and easier to understand than current code.