This is the mail archive of the archer@sourceware.org mailing list for the Archer project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]