From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2197 invoked by alias); 17 Apr 2014 09:54:12 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 2188 invoked by uid 89); 17 Apr 2014 09:54:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_NEUTRAL autolearn=no version=3.3.2 X-HELO: sasl.smtp.pobox.com Received: from a-pb-sasl-quonix.pobox.com (HELO sasl.smtp.pobox.com) (208.72.237.25) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 17 Apr 2014 09:54:10 +0000 Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 0A80D11E8A; Thu, 17 Apr 2014 05:54:09 -0400 (EDT) Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 0112C11E89; Thu, 17 Apr 2014 05:54:09 -0400 (EDT) Received: from rusty (unknown [88.160.190.192]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 3E7A011E88; Thu, 17 Apr 2014 05:54:06 -0400 (EDT) From: Andy Wingo To: Doug Evans Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 6/9] Remove Guile GDB object property mechanism References: <1397060028-18158-1-git-send-email-wingo@igalia.com> <1397060028-18158-7-git-send-email-wingo@igalia.com> Date: Thu, 17 Apr 2014 09:54:00 -0000 In-Reply-To: (Doug Evans's message of "Sat, 12 Apr 2014 12:23:26 -0700") Message-ID: <878ur4s2mb.fsf@igalia.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Pobox-Relay-ID: 377D3A4A-C616-11E3-8326-873F0E5B5709-02397024!a-pb-sasl-quonix.pobox.com X-SW-Source: 2014-04/txt/msg00344.txt.bz2 On Sat 12 Apr 2014 21:23, Doug Evans writes: > Andy Wingo 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