On Thu, 02 Feb 2017 17:16:49 +0100, John Brant
<br...@refactoryworkers.com> wrote:
On 02/02/2017 04:22 AM, Denis Kudriashov wrote:
Now I think I realized main reason of my confusion. Temps and receiver
vars are not just in single table but they are also sorted by name all
together.
I'm not a fan of this either. While I can filter by the type of variable
to limit the list, the next time I step the debugger, the whole list
resets. The list filter and selection should be kept across steps in the
debugger (if possible).
Some might argue that you should have fewer variables so the list would
be easier to use in the debugger. However, if you are using the
debugger, likely you are still in the "make it work" phase and haven't
performed the factoring from the "make it right" phase.
+ 1 and under stress
I think my preference would be to have several tabs for the variables.
In addition to the one tab that we have now that shows all variables, I
can think of tabs for locals, inst vars, interesting variables, watched
variables/expressions, and stack variables. Locals would show just the
method/block arguments and any temps defined in the method. Inst vars
would show the object's inst vars (and maybe class vars, however these
would only appear after the inst vars).
Interesting variables would show locals and inst vars used by the
method. The locals would be limited to the ones that are still active at
the current location in the method. For example, if you are in a block,
it would only show variables used in the block. Also, if you are
before(/after) the first(/final) use of the variable, it wouldn't show
in the interesting list. Interesting variables should also do some
analysis to see what accessor methods are used and show their
corresponding variables.
I like that
Watched variables/expressions would be user controlled. The user could
add/remove variables or expressions. These variables/expressions would
remain across different methods. If a variable didn't exist in the other
method, "Invalid" could be displayed.
Finally, stack variables would display the whole stack and not just the
top item. I like the ability to see the stack top, but it really doesn't
work if you want to see the first argument of a two argument message
send. For example, if you debug "Array with: OrderedCollection new with:
Set new", stepping over the "OrderedCollection new" immediately pushes
the "Set" class on the stack so you can't see the "OrderedCollection
new" object.
I like that now when we have too many tabs it often happens that
only two are useful.
BTW, the current variable list sometimes shows 'error obtaining field
value' for temporaries when stepping through a method. I'm not sure why
it occurs, but it should always be able to display the temp variables.
John Brant
--
Using Opera's mail client: http://www.opera.com/mail/
