Re: [rfc] expose gdb values to python

[Tom Tromey <tromey@redhat.com>]

>>>>> "Thiago" == Thiago Jung Bauermann <bauerman@br.ibm.com> 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