Re: Frames as scopes

[Tom Tromey <tromey at redhat dot com>]

>> I don't think there's a deep reason to prefer one or the other.  There
>> are plenty of examples of successful projects using either.  I just
>> tend to prefer not having a separate thin, low-level API that must be
>> explained as well.

Doug> Fair enough, though I don't think I was arguing for the extreme end of
Doug> the spectrum ("as thin as possible").

Yeah, sorry, I wasn't trying to put words in your mouth.

Doug> Routines with defaults raise a flag for me.

I don't mind approaching it case-by-case, either, fwiw.

Doug> OOC, on a semi-related note, how much global state is being bubbled up
Doug> into the python API? [current/selected frame, et.al.]
Doug> gdb.lookup_symbol doesn't appear to specify which process, for
Doug> example.  GDB already has too many globals.  Some are reasonable given
Doug> gdb is an interactive program (having to pass a process/thread id to
Doug> "x/i $pc", etc. would be a pain ...).  OTOH, it'd be nice (I think!)
Doug> to eschew them in the python api (all else being equal).

Yeah, I agree.  I was hoping to change some of the things which are
currently "global" (or global-dependent, however you want to phrase
that) into methods on Inferior.

I'm not sure how far to push this, though, since I'm also reluctant to
get into a situation where we are trying to write an API that is
somehow at odds with the underlying gdb.  IOW, perhaps these
transforms ought to be more than skin deep.

That is kind of an abstract worry.  I think we'll have to look at
individual cases more closely.

Tom