This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [doc] improve MI varobj introduction
> From: Vladimir Prus <ghost@cs.msu.su>
> Date: Mon, 08 Jan 2007 17:49:12 +0300
> >
> > Variable objects are an MI convenience feature to reference
> > expressions. When a frontend creates a variable object, it
> > specifies a name for an arbitrary expression in the debugged
> > program. That name can henceforth be used as an opaque handle for
> > the expression. The expression can be a simple variable, or it can
> > be ...
> >
> > Okay?
>
> You're right that my text did not say why it's recommended, but I think the
> above is also not accurate. "convenient feature to reference expressions"
> is not quite right -- it sounds like varobj is just a method to create
> aliases for expression, and varobjs are much more than that. How about:
>
> Variable objects are "object-oriented" MI interface for
> examining and changing values of expressions. Unlike some other
> MI interfaces that work with expressions, variable objects are
> specifically designed for simple and efficient
> presentation in the frontend. A variable object is identified
> by string name. When a variable object is created, the
> frontend specifies the expression for that variable object.
> The expression can be a simple variable ........
The first two sentences sound to me more like advertisement, but if
you feel you need to say that, fine.
> > A child variable object can itself have children, until we reach
> > leaf variable objects which have built-in types.
>
> That looks fine for me, but should not we have a command before "which"?
> Otherwise, it sounds like there are two kind of leaf variable objects --
> those of builtin types and those of non-builtin types.
I just tried to make a minimal modification of your text. Perhaps a
better variant is this:
A child variable object can itself have children, recursively.
Recursion ends when we reach leaf variable objects that have
built-in types.