This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 6/9] Remove Guile GDB object property mechanism
- From: Doug Evans <xdje42 at gmail dot com>
- To: Andy Wingo <wingo at igalia dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Sat, 12 Apr 2014 12:23:26 -0700
- Subject: Re: [PATCH 6/9] Remove Guile GDB object property mechanism
- Authentication-results: sourceware.org; auth=none
- References: <1397060028-18158-1-git-send-email-wingo at igalia dot com> <1397060028-18158-7-git-send-email-wingo at igalia dot com>
Andy Wingo <wingo@igalia.com> writes:
> * gdb/guile/guile-internal.h: Remove scm_gsmob / GDB_SMOB_HEAD base
> type; it only served as something to which object properties could be
> attached: a use case already served by Guile's own object properties.
> (gdbscm_init_gsmob, gdbscm_mark_gsmob, gdbscm_mark_chained_gsmob)
> (gdbscm_mark_eqable_gsmob): Remove these now-unneeded functions.
>
> * gdb/guile/scm-gsmob.c (gdbscm_init_gsmob, gdbscm_mark_gsmob)
> (gdbscm_mark_chained_gsmob, gdbscm_mark_eqable_gsmob): Remove.
> (gdbscm_gsmob_property, gdbscm_set_gsmob_property_x)
> (gdbscm_gsmob_has_property_p, add_property_name)
> (gdbscm_gsmob_properties): Remove these public interfaces, and remove
> them from gsmob_functions.
>
> * gdb/guile/scm-arch.c:
> * gdb/guile/scm-block.c:
> * gdb/guile/scm-breakpoint.c:
> * gdb/guile/scm-exception.c:
> * gdb/guile/scm-frame.c:
> * gdb/guile/scm-iterator.c:
> * gdb/guile/scm-lazy-string.c:
> * gdb/guile/scm-objfile.c:
> * gdb/guile/scm-pretty-print.c:
> * gdb/guile/scm-symbol.c:
> * gdb/guile/scm-symtab.c:
> * gdb/guile/scm-type.c:
> * gdb/guile/scm-value.c: Adapt to not include a gdb_gsmob base member,
> for basic gsmobs, and to not call init/mark functions.
I realize I wasn't going to say anything more about changelogs, but alas
the above is insufficient. My understanding of community rules, and I
can imagine there being differing opinions, is that shortcuts like this
are not allowed. No disagreement that some brevity would be nice, but
IME the community frowns on it. [More clarity on the subject would be nice.]
Each change to each file needs to be documented. E.g.,
* scm-arch.c (_arch_smob): Delete member base. All uses updated.
or some such, depending on the change.
I started out with having a simple "aux" field in gsmobs so that
one could store arbitrary data with them without having to resort to
object properties (storing data for an "object" in a global side table
is a hack I'm not fond of).
I think I'll go back to having just "aux".