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

>>>>> "Siva" == Siva Chandra <[email protected]> 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.

Thanks.

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.

Likewise.

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" [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).

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
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.

I don't understand this one.

Tom