This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA] Re: Python: add field access by name and standard python mapping methods to gdb.Type


On Nov 4, 2011, at 7:04 PM, Doug Evans wrote:

> On Fri, Nov 4, 2011 at 1:40 PM, Paul Koning <paulkoning@comcast.net> wrote:
>> 
>> 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.
> 
> For structs and such sure, but not so for scalars.
> Scalars shouldn't behave like a dictionary.

Quite right.

> 
> If we're going for consistency between gdb.Value and gdb.Type then for
> structs and such we'll need len(gdb.Value) to return the number of
> fields. [Right?]

Yes, and that's part of what I intend to propose.
> 
> Maybe I'd be happy if gdb.Type (and maybe gdb.Value) were simply more
> rigorous in throwing exceptions for invalid cases.

I agree.  I'll put that together.

	paul


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]