Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Paul Koning <paulkoning@comcast.net>
To: Doug Evans <dje@google.com>
Cc: Eli Zaretskii <eliz@gnu.org>,
	tromey@redhat.com, gdb-patches@sourceware.org
Subject: Re: [RFA] Re: Python: add field access by name and standard python mapping methods to gdb.Type
Date: Fri, 04 Nov 2011 20:41:00 -0000	[thread overview]
Message-ID: <37B202A1-DCD5-423E-8E30-55A6F2BE21EF@comcast.net> (raw)
In-Reply-To: <CADPb22RSiVqCj3USYBw=Bbi88=mi_HtZSPSAwJO61-JR8POP8w@mail.gmail.com>


On Nov 4, 2011, at 1:41 PM, Doug Evans wrote:

> On Tue, Oct 4, 2011 at 8:56 AM, Paul Koning <paulkoning@comcast.net> wrote:
>> 
>> On Oct 4, 2011, at 11:41 AM, Eli Zaretskii wrote:
>> 
>>>> From: Paul Koning <paulkoning@comcast.net>
>>>> Date: Tue, 4 Oct 2011 11:29:58 -0400
>>>> Cc: Doug Evans <dje@google.com>, gdb-patches@sourceware.org
>>>> 
>>>> 
>>>>> For future reference, there is a separate ChangeLog in doc.  Entries for
>>>>> documentation have to go there.
>>>> 
>>>> I overlooked that file.  Thanks for the reference.  Should I move the entry there?
>>> 
>>> Yes, please.
>> 
>> Done.
>> 
>>> 
>>>>> Could you write a NEWS entry for this change?
>>>> 
>>>> How about this?
>>> 
>>> Fine with me, thanks.
>> 
>> Committed.
> 
> Ummm, hi.
> I know I looked at the patch and approved it myself, but having played
> with it for awhile I'm having second thoughts.
> And before a release goes out I'd like to get this resolved.
> If you want I'll do the work, or at least help however I can.
> 
> One way to look at my reasoning is that a type "has a" field list but
> it's not the case that a type "is a" field list.
> And I'm uncomfortable with len(gdb.parse_and_eval("1").type) == 0.
> IOW, len(gdb.Type of "int") is now 0.  I think it should flag an exception.
> 
> OTOH, adding the new support to the result of gdb.Type.fields() is great.
> 
> Anyone object to me changing things and moving the new iterator
> support to gdb.Type.fields()?
> Or do people disagree with my reasoning?
> I haven't looked into what's involved.  At this point I just want to
> get the user-visible semantics right.

Part of my reasoning is to have gdb.Value and gdb.Type look alike.  gdb.Value always had field lookup by name, i.e., it behaves like a Python dictionary.  So I wanted to make the same apply to gdb.Type since the analogy seemed obvious.  And in both cases, I wanted the normal Python dict methods to be available.  (For gdb.Value, that's not submitted yet.)

In my view, gdb.Type.fields remains as a backward compatibility synonym for gdb.Type.values (the standard dict method).

I do agree that having len() return 0 instead of an error seems wrong.

	paul


  reply	other threads:[~2011-11-04 20:41 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-16  4:09 Paul Koning
2011-09-16  7:36 ` Eli Zaretskii
2011-09-16 10:47 ` Phil Muldoon
2011-09-16 14:57   ` Paul Koning
2011-09-16 14:57     ` Phil Muldoon
2011-09-16 15:41   ` Paul Koning
2011-09-23 17:21     ` Doug Evans
2011-09-26 17:15       ` [RFA] " Paul Koning
2011-09-28 19:25         ` Doug Evans
2011-09-28 20:41           ` Paul Koning
2011-10-04 15:14             ` Tom Tromey
2011-10-04 15:30               ` Paul Koning
2011-10-04 15:42                 ` Eli Zaretskii
2011-10-04 15:56                   ` Paul Koning
2011-11-04 17:42                     ` Doug Evans
2011-11-04 20:41                       ` Paul Koning [this message]
2011-11-04 23:05                         ` Doug Evans
2011-11-05 14:36                           ` Paul Koning
2011-11-05 21:04                             ` Doug Evans
2011-11-08 21:40                               ` [RFA] Python: raise exception on field-related gdb.Type methods if it's not struct or union Paul Koning
2011-11-09  0:29                                 ` Doug Evans
2011-11-09  1:53                                   ` Paul Koning
2011-11-09 18:10                                   ` Paul Koning
2011-11-15 19:01                                     ` [PING] " Paul Koning
2011-11-15 20:57                                       ` Doug Evans
2011-11-15 21:21                                         ` Paul Koning

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=37B202A1-DCD5-423E-8E30-55A6F2BE21EF@comcast.net \
    --to=paulkoning@comcast.net \
    --cc=dje@google.com \
    --cc=eliz@gnu.org \
    --cc=gdb-patches@sourceware.org \
    --cc=tromey@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox