Re: [rfc] expose gdb values to python

[Tom Tromey <tromey@redhat.com>]

>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> 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