From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8482 invoked by alias); 26 Sep 2008 23:08:50 -0000 Received: (qmail 8472 invoked by uid 22791); 26 Sep 2008 23:08:49 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 26 Sep 2008 23:08:15 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m8QN8DJ9001807 for ; Fri, 26 Sep 2008 19:08:13 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m8QN8DR2021762 for ; Fri, 26 Sep 2008 19:08:13 -0400 Received: from opsy.redhat.com (vpn-10-95.bos.redhat.com [10.16.10.95]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id m8QN8CP3023647; Fri, 26 Sep 2008 19:08:12 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 3D42737824E; Fri, 26 Sep 2008 17:07:13 -0600 (MDT) To: Thiago Jung Bauermann Cc: gdb-patches@sources.redhat.com Subject: Re: [rfc] expose gdb values to python References: <1221199426.24580.26.camel@localhost.localdomain> From: Tom Tromey Reply-To: tromey@redhat.com X-Attribution: Tom Date: Fri, 26 Sep 2008 23:08:00 -0000 In-Reply-To: (Thiago Jung Bauermann's message of "Thu\, 25 Sep 2008 01\:48\:45 -0300") 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-09/txt/msg00531.txt.bz2 Tom> There are some tradeoffs here. The "invisible access" approach is Tom> convenient. However, it runs into issues with odd programs -- say, Tom> multiple inheritance where a given name refers to multiple fields. Thiago> Adding a way to do casting in python solves this, right? Yes. Tom> I tend to like something toward the raw side, partly because any Tom> cooked approach will still need some second way to deal with the Tom> underlying explicit types. Thiago> Sorry, I didn't understand "deal with the underlying explicit types". That is just a funny way of saying, we'll still need the casting, and of course some way to get the list of superclasses. Tom> I propose we decide these questions and implement this before checking Tom> in this patch. The semantics of Value are critical. Thiago> Right. I suggest people to take a look at the testcase to see Thiago> what the syntax looks like, and speak up if there are any Thiago> concerns or preferences. The tricky cases all occur when using inheritance and having conflicting names. Tom