GNU bug report logs - #12215
CSET is unnecessarily confusing

Previous Next

Full log

Message #28 received at 12215 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Dmitry Antipov <dmantipov <at> yandex.ru>, 12215 <at> debbugs.gnu.org
Subject: Re: bug#12215: CSET is unnecessarily confusing
Date: Wed, 22 Aug 2012 09:35:24 -0700

On 08/22/2012 06:27 AM, Stefan Monnier wrote:
>> That does avoid the ambiguity but it's pretty weird.
> Less weird than CSET (XCHAR_TABLE (char_table), parent, parent),
> and avoids the duplication of code we have with set_char_table_foobar.

True in both cases.  I suppose the notation could grow on one.

A few other thoughts.  First, why would we need multiple setter
macros (CSET, BSET, etc.)?  Why can't we have just one macro?
That is, why does CSET (P, .FIELD, VAL) care what P's type is?
Surely one generic macro will do.

Second, why does the setter need the pointer to the start of
the object, as well as a pointer to the field that's changing?
Doesn't the latter suffice in a copying collector?  That is,
why can't we just turn this into something like:

   fset (&XCHAR_TABLE (char_table)->parent, parent);

?  That's shorter and simpler and avoids the need for a macro.

Third, I agree with Stefan that it'd be reasonable to put all
this setter stuff into a branch, and I'll volunteer to do
that (i.e., change back to plain assignments in the trunk,
and create a new branch called "gc" or whatever).  But I recall
that Dmitry had serious qualms about that so I would like to
hear his opinion.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.