This is the mail archive of the
archer@sourceware.org
mailing list for the Archer project.
Re: Frames as scopes
On Mon, Jan 5, 2009 at 4:07 PM, Tom Tromey <tromey@redhat.com> wrote:
> Anyway... the direction my thoughts have been headed for the built-in
> API is that it should be a reasonable API on its own.
>
> There are other approaches -- there's the "SWT approach", which is to
> make the glue layer as thin as possible and then do everything in the
> higher level language.
>
> 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.
Fair enough, though I don't think I was arguing for the extreme end of
the spectrum ("as thin as possible"). Routines with defaults raise a
flag for me.
OOC, on a semi-related note, how much global state is being bubbled up
into the python API? [current/selected frame, et.al.]
gdb.lookup_symbol doesn't appear to specify which process, for
example. GDB already has too many globals. Some are reasonable given
gdb is an interactive program (having to pass a process/thread id to
"x/i $pc", etc. would be a pain ...). OTOH, it'd be nice (I think!)
to eschew them in the python api (all else being equal).