From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17436 invoked by alias); 8 Jan 2007 19:45:44 -0000 Received: (qmail 17426 invoked by uid 22791); 8 Jan 2007 19:45:43 -0000 X-Spam-Check-By: sourceware.org Received: from romy.inter.net.il (HELO romy.inter.net.il) (192.114.186.66) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 08 Jan 2007 19:45:38 +0000 Received: from HOME-C4E4A596F7 (IGLD-80-230-23-29.inter.net.il [80.230.23.29]) by romy.inter.net.il (MOS 3.7.3-GA) with ESMTP id GTL92583 (AUTH halo1); Mon, 8 Jan 2007 21:45:34 +0200 (IST) Date: Mon, 08 Jan 2007 19:45:00 -0000 Message-Id: From: Eli Zaretskii To: Vladimir Prus CC: gdb-patches@sources.redhat.com In-reply-to: (message from Vladimir Prus on Mon, 08 Jan 2007 17:49:12 +0300) Subject: Re: [doc] improve MI varobj introduction Reply-to: Eli Zaretskii References: <200612191103.55137.vladimir@codesourcery.com> <200701051139.09498.ghost@cs.msu.su> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-01/txt/msg00239.txt.bz2 > From: Vladimir Prus > 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.