Re: [PATCH 6/9] Remove Guile GDB object property mechanism

[Andy Wingo <wingo@igalia.com>]

On Sat 12 Apr 2014 21:23, Doug Evans <xdje42@gmail.com> writes:

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

Alack.  Will fix, but what a slog...

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

Just my opinion, but I think this is the wrong approach.  For one, you
have to make a new API, where there is a perfectly good and
well-understood one in Guile.  Less code is better code.  You add
overhead for these properties to every object, where the vast majority
of objects will never need it.  It doesn't compose on a modular level --
you can't hide a property on an object from other modules, as you can
with `make-object-property'.  And finally, a weak lookaside table is a
semantically equivalent option, and is not bad, perf-wise.

Again, just MHO :)

Regards,

Andy