Re: Questions about MI variable objects

[Jim Blandy <jimb@codesourcery.com>]

Vladimir Prus <ghost@cs.msu.su> writes:
>> Suppose I'm stopped where the stack is like this:
>> 
>>     main -> foo (2) -> foo (1) -> foo (0)
>> 
>> Suppose the top frame is selected, and the user adds a display for
>> 'x'.  Clearly, it should show '0'.
>
> You're using an ill-defined term "adds a display". 

Well, sure.  I'm asking people to tell me about all the GUIs they work
on, so I can't use specific language.

>> 4) If the user lets control run to 'foo' again, so the stack now looks
>>    like:
>> 
>>        main -> bar (10) -> foo (9)
>> 
>>    what should happen to the display of 'x'?  (I'd say it should show
>>    '9'.)
>
> I agree.
>
> I think that @-variable-object should behave as described above.

Right; I wasn't aware of '@'-frame varobjs when I originally wrote,
since they're not documented.

> Note also that it's possible to imagine GUI commands that show a
> value of some expression in particular "scope", and became
> forever grayed out when that scope dies. It raises numerous
> questions how to identify scopes. It should be noted that KDevelop
> does not have such UI command, and it was never requested.

Yeah, it doesn't seem too useful.

>> The principle behind my guesses is that a display should refer to a
>> particular variable in the source code --- a particular declaration
>> --- and should show its value whenever that declaration is in scope in
>> the selected frame.  This is less specific than having the display
>> refer to a particular frame's instance of that variable, and more
>> specific than having it refer to any variable that happens to be in
>> scope under that name.  But it's what I'd expect from a GUI.
>
> This seem to contradict your claim that in 'bar', we should show '9'
> for 'x' -- it's different 'x', after all. 

You misread --- I said we should show '9' in the first call to foo
from bar.

> Assume user asked to show value of "x+y". There are three alternatives:
>
> 1. Show value of that expression in specific frame, gray it out
> otherwise.
> 2. Show value of that expression in current frame, provided "x" and "y"
> refer to the same language declaration.
> 3. Show value of that expression in current frame.
>
> (3) is what implemented by @-varobjs. You seem to propose (2),
> which will only differ from (2) by the fact that sometimes (3) will show
> a value and (2) will have value greyed. Is this big enough deal to
> worry about?

Yes, that is the distinction.  If it's not important to GUI
implementors, then it's certainly not a big enough deal to worry
about.

> As for (1), it's implemented by ordinary varobjs. 

Except for the frame collision behavior which I demonstrated, yes.