This is the mail archive of the
mailing list for the GDB project.
Re: Invoking methods on gdb.Value objects and other ideas
- From: Siva Chandra <sivachandra at google dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: gdb at sourceware dot org
- Date: Mon, 16 Dec 2013 16:55:51 -0800
- 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> <87bo0gpg4f dot fsf at fleche dot redhat dot com>
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.
Tom> It seems to me that #5 and #6 are just two different ways to write the
Tom> same thing. More or less.
Yes, more or less :-)
But, note that the method "get_method" takes a string arg, whereas the
operand to '' is _not_ a string. It is a gdb.TypeMethod or
Tom> Note that a danger of using strings and overloading  is that in Java
Tom> (and maybe other languages, I don't know) a method and an ordinary field
Tom> can have the same name. I think this would make the syntax ambiguous
Tom> there -- is value['name'] a reference to a field or to a bound method?
As I mentioned above, we do not use a string operand with '' to get methods.
Tom> Perhaps having just get_method is better for this reason.
But, do you think we should not have support for '' as described above?
Tom> The above seem to be found methods, but it seems that to be complete
Tom> you'd also want a way to create a C++ pointer-to-member. I guess this
Tom> is more cleanly done via the Type API, or perhaps a method on your
Tom> proposed TypeMethod object.
I think you mean "bound" methods. I refrained from using that term as
they could be yet unresolved, and they are not gdb.TypeMethod or
gdb.ValueMethod objects. But, I do not have any real reason to not
call them bound methods.
About C++ pointer-to-member values, I think they are in a way methods
already, and hence could just be invoked by '(...)' method invocation?
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).
Tom> I wasn't sure about this but I think the idea must be that the internals
Tom> cache the result of some other lookup; so that having multiple structs
Tom> representing the same type can't cause a problem. So, it is a
Tom> 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.
Tom> I don't understand this one.
I think you should ignore #7, #8 and #9. My mistake to have mixed
them up here with the discussion on method invocation.