Eli Zaretskii wrote:

>> 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.

Yes, I feel we need to emphasise that varobjs is what folks should use,
not some convenience that might be ignored.

> 
>> >   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.

Again, "that have built-in types" sounds to me like restrictive clause,
as if there are leaf variables that don't have builtin-types. What about:

        Recursion ends when we reach leaf variable objects, which always have
        built-in types.

I attach the revised patch, incorporating those two corrections,
and using the above last sentence. Is it OK, or would you prefer 
your original sentence? 

Thanks,
Volodya