From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16939 invoked by alias); 20 Sep 2008 21:29:49 -0000 Received: (qmail 16931 invoked by uid 22791); 20 Sep 2008 21:29:48 -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; Sat, 20 Sep 2008 21:29:03 +0000 Received: from int-mx01.intranet.prod.int.phx2.redhat.com (int-mx01.intranet.prod.int.phx2.redhat.com [10.5.30.51]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id m8KLSwwV015345; Sat, 20 Sep 2008 17:28:58 -0400 Received: from opsy.redhat.com ([10.16.10.85]) by int-mx01.intranet.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id m8KLSvo1027351; Sat, 20 Sep 2008 17:28:58 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id B13B53785D0; Sat, 20 Sep 2008 15:28:28 -0600 (MDT) To: Thiago Jung Bauermann Cc: gdb-patches ml 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: Sat, 20 Sep 2008 21:29:00 -0000 In-Reply-To: <1221199426.24580.26.camel@localhost.localdomain> (Thiago Jung Bauermann's message of "Fri\, 12 Sep 2008 03\:03\:46 -0300") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 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/msg00447.txt.bz2 >>>>> "Thiago" == Thiago Jung Bauermann writes: Thiago> This is the patch exposing struct value to Python. Thank you so much, not just for this patch, but for all your work separating the mess into patches. Thiago> I believe it's better to avoid using current_language, right? Thiago> I don't think there's a way to get a sensible language_defn to Thiago> use here, so my only idea is to add an element to struct value Thiago> which holds the language associated with the value. This Thiago> element would be filled at the moment the value is created. My first reaction to this was "no way". But, I couldn't think of a concrete case where this would have bad results -- especially provided we restrict use of the language field to stringifying the value. Thiago> The other FIXME is for the bogus implementation of Thiago> valpy_length, which is supposed to return the number of Thiago> elements in the gdb.Value fake dictionary. I had a quick look Thiago> at how I'd enumerate all elements in a struct/class to find a Thiago> sensible answer, but I got scared by the code in Thiago> value_struct_elt and friends. I think there are a few ways to approach this. 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"]? There are some tradeoffs here. The "invisible access" approach is convenient. However, it runs into issues with odd programs -- say, multiple inheritance where a given name refers to multiple fields. The "raw" approach doesn't have this problem (and here, valpy_length is easy to write), but it is more cumbersome to use. There are some intermediate ideas, too, like allowing the invisible approach only when the field name is unique; or we could define the search order. (It is tempting to use the language's rules, but I suspect this might be too tricky to get right.) I tend to like something toward the raw side, partly because any cooked approach will still need some second way to deal with the underlying explicit types. I propose we decide these questions and implement this before checking in this patch. The semantics of Value are critical. Tom