From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5687 invoked by alias); 1 Oct 2008 15:12:09 -0000 Received: (qmail 5679 invoked by uid 22791); 1 Oct 2008 15:12:08 -0000 X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 01 Oct 2008 15:11:33 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id m91FB2EX006373; Wed, 1 Oct 2008 11:11:02 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m91FB1U2016363; Wed, 1 Oct 2008 11:11:01 -0400 Received: from opsy.redhat.com (vpn-10-132.bos.redhat.com [10.16.10.132]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id m91FAwC8017234; Wed, 1 Oct 2008 11:11:00 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 143BE3785CF; Wed, 1 Oct 2008 09:09:36 -0600 (MDT) To: Joel Brobecker Cc: Thiago Jung Bauermann , gdb-patches ml Subject: Re: [rfc] expose gdb values to python References: <1221199426.24580.26.camel@localhost.localdomain> <20081001054741.GE3665@adacore.com> From: Tom Tromey Reply-To: tromey@redhat.com X-Attribution: Tom Date: Wed, 01 Oct 2008 15:12:00 -0000 In-Reply-To: <20081001054741.GE3665@adacore.com> (Joel Brobecker's message of "Tue\, 30 Sep 2008 22\:47\:41 -0700") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: 2008-10/txt/msg00014.txt.bz2 >>>>> "Joel" == Joel Brobecker writes: >> The underlying question is what type model Value presents. If a Value >> has a derived type, should we be able to access fields of the base >> class using v["f"]? Or should we need v["Base"]["f"]? Joel> My initial reaction to this question is that the Value object Joel> should follow the same semantics as the debugger. By this I take you to mean the semantics of the currently selected language...? Joel> For instance, if class Foo inherits from class Bar, then any Joel> component of class Bar should be directly visible from class Joel> Foo. So if X is Value of type class Foo, and class Bar has a Joel> component named "Baz", then I should be able to access that Joel> component with X["Baz"]. This is the bad case: class B1 { int x; }; class B2 { int x; }; class D : B1, B2 { }; Suppose you have a Value v whose type is "D". An extension author needs a way to access each 'x'. I think the current proposal is to try to follow the current language, and then have the user cast 'v' to B1 or B2 if needed. The reason I prefer the other, more explicit, approach is that the meaning of python code does not change depending on a user's language setting. However, it is more typing, which is a drawback. Joel> Better yet, I would love for the object to have one attribute Joel> for each component that I could simply access using X.baz. Joel> But I suspect that there is no way we can implement that without Joel> having to compute the value of each component, which would be Joel> quite wastful the vast majority of the time. Sigh, is it not Joel> possible to lazy-initialize attributes? I think we can do this, but there is a cost, namely conflicts between methods on Value and field names in the inferior will have to be resolved in favor of the method. So, robust programs will always have to use the [] syntax anyway. Tom