emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r109327: Generalize INTERNAL_FIEL


From: Stefan Monnier
Subject: Re: [Emacs-diffs] /srv/bzr/emacs/trunk r109327: Generalize INTERNAL_FIELD between buffers, keyboards and frames.
Date: Wed, 08 Aug 2012 08:41:54 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux)

> Another problem, which I haven't seen mentioned in this thread, is that
> when you see C code which does FVAR (x, y) the natural assumption is
> that x and y are C variables.  So these macros hurt code readability.

> The introduction of BVAR also violated this principle, and I'm not eager
> to see the problem compounded.

Yes, we should see about fixing this problem.

> I think FSET/WSET/PSET/PGET/etc should be removed from the trunk, at
> least for now.  I recommend moving the generational GC work to a branch.

I'm OK with keeping macros for the assignments.  But I'd like to hear
suggestions to reduce/eliminate the problem you mention (of field names
looking like variables).
Depending on the write-barrier, "FSET (foo->bar, val)" can be used, but
most write-barriers want to access other parts of "foo" rather than only
"foo->bar".
Maybe SET_FIELD (foo, bar, val) would be slightly better: "bar" still
looks like a variable, but at least the macro name hints at the fact
that there's a field somewhere in there.

> Isn't the point of Coccinelle to make it possible to transform the code
> with minimal manual intervention?

IIUC Coccinelle helps the work, but there is still a fair bit of manual
intervention needed afterwards, so it's not quite that simple.


        Setfan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]