Re: Invoking methods on gdb.Value objects and other ideas

[Siva Chandra <sivachandra@google.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
gdb.ValueMethod object.

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" [3] - 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
Tom> machinery.

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.