Re: [python][patch] Pretty printers for anonymous types.

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Jeffrey" == Jeffrey Yasskin <jyasskin@google.com> writes:

Jeffrey> Here's a thought for the interface; sorry if it's totally
Jeffrey> unimplementable or you've already considered and rejected it.

I don't recall why I chose the approach I did.  Perhaps just because I
had to start somewhere, and it was simple.

Jeffrey> You currently take a dict of regex->printer pairs, but you're using it
Jeffrey> just as a set of pairs since you can't reverse-engineer the regex from
Jeffrey> the type. What about, instead, if you let the first element of the
Jeffrey> pair be any function from a gdb.Type->bool?

This seems reasonable to me.  It would also let us solve the
inheritance issue in a nice way.

I can't think of any drawbacks.  Anybody?

I've also been wondering whether we want to continue using a map, or
whether it would be better to have an explicit sequence of pairs.  A
sequence would permit control over the order in which predicates are
run.

Finally, right now we search maps of all the objfiles, in order, and
then the global pretty_printers map.  I've been wondering whether we
should search the type's objfile (if there is one) first.

I welcome your thoughts on any of this.  We're getting close to
submitting a bunch of this upstream, in preparation for GDB 7.0, so
now is a good time to deal with any lingering problems.

Jeffrey> Then, assuming that gdb.Type(x_typedef)==gdb.Type(x)

This is not the case -- but I don't think it matters.

It would not be hard to add a method to Type to strip the typdefs.
Then a comparison like that could be written easily:

   x_typedef.strip() == x.strip()

(Not sure about that name, it is just an example.)

Also, Type doesn't even have a meaningful comparison operator at the
moment.  Adding this has been on my to-do list for a while.  As I
recall, right now the glue code can construct more than one Type
object representing the same underlying struct type.

Jeffrey> It's straightforward to write a generator for such predicates
Jeffrey> for regexes to maintain compatibility:

FWIW -- until we push into upstream gdb (soon) or ship in Fedora (also
soon), I'm not super concerned about compatibility.

Even so we could also achieve it by just switching on the type of the
key in the map -- if it is a string, do what we do now, else invoke
the predicate.  I'm sort of hoping that we can cover up our inevitable
API mistakes this way, i.e., by using dynamic language features to
maintain backward compatibility.  This seems to work reasonably well
for Emacs.  The results aren't always pretty though.

Tom