This is the mail archive of the
mailing list for the GDB project.
Re: Invoking methods on gdb.Value objects and other ideas
- From: Tom Tromey <tromey at redhat dot com>
- To: Siva Chandra <sivachandra at google dot com>
- Cc: gdb at sourceware dot org
- Date: Mon, 16 Dec 2013 15:48:00 -0700
- Subject: Re: Invoking methods on gdb.Value objects and other ideas
- Authentication-results: sourceware.org; auth=none
- References: <CAGyQ6gxs7NCTSdMvBMxTthvVb1zQD-uYfU2OmLpVUcDEhwNYOA at mail dot gmail dot com>
>>>>> "Siva" == Siva Chandra <firstname.lastname@example.org> writes:
Siva> I am sharing some of my ideas on how we could facilitate invoking
Siva> source language methods (and debug methods) on gdb.Value objects.
Siva> 1. Bring in a class hierarchy of gdb types. That is, have a base class
Siva> gdb.Type from which other classes gdb.TypeStruct, gdb.TypeMethod etc
Siva> are derived.
Sounds good. We probably should have done it from the start.
Siva> 2. Do the same with gdb.Value class. That is, have a base class
Siva> gdb.Value from which other classes gdb.ValueStruct, gdb.ValueMethod
Siva> etc. are derived. I am not very sure if this is really required, but I
Siva> can think of atleast one reason why this can be cleaner.
Siva> 5. Method invocation via  operator - One should be able to invoke
Siva> methods on a gdb.Value object like this:
Siva> value_obj[method](arg1, arg2, ...)
Siva> METHOD can be a gdb.TypeMethod, or a gdb.ValueMethod object.
Siva> 6. Unresolved methods - Value and type objects should have Python
Siva> method "get_method".
Siva> m = value_obj.get_method(method)
Siva> METHOD is a string value name of the method. M is a yet unresolved
Siva> method (due to overloading) but can used to invoke the method like in
Siva> 4 and 5 above. The method is resolved based on the args.
It seems to me that #5 and #6 are just two different ways to write the
same thing. More or less.
Note that a danger of using strings and overloading  is that in Java
(and maybe other languages, I don't know) a method and an ordinary field
can have the same name. I think this would make the syntax ambiguous
there -- is value['name'] a reference to a field or to a bound method?
Perhaps having just get_method is better for this reason.
The above seem to be found methods, but it seems that to be complete
you'd also want a way to create a C++ pointer-to-member. I guess this
is more cleanly done via the Type API, or perhaps a method on your
proposed TypeMethod object.
Siva> 8. Debug method caching in the underlying "struct type"  - If a
Siva> particular debug matches for a type, then cache it in the type. Future
Siva> similar invocations need go through all debug methods for a match
Siva> (unless of course new debug methods are registered in the meanwhile).
I wasn't sure about this but I think the idea must be that the internals
cache the result of some other lookup; so that having multiple structs
representing the same type can't cause a problem. So, it is a
performance optimization rather than an integral part of the lookup
Siva> 9. Caching debug methods matches to disk - This is for a use case
Siva> wherein a GDB user does not write his own debug methods but ends up
Siva> implicitly using debug methods defined for a library not written by
Siva> him. For such cases, one could cache the debug method matches to disk
Siva> so that future GDB sessions save on debug method search.
I don't understand this one.