[Top][All Lists]

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

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

From: Paul Eggert
Subject: Re: [Emacs-diffs] /srv/bzr/emacs/trunk r109327: Generalize INTERNAL_FIELD between buffers, keyboards and frames.
Date: Fri, 03 Aug 2012 11:58:21 -0700
User-agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0

On 08/03/2012 01:31 AM, Dmitry Antipov wrote:
> why (F|W)VARs are so bad but (B|K)VARs are OK?

The short answer is they're all bad.  :-)

FVAR is bad partly because it has the syntax of a C function,
but not the semantics; it cannot be implemented as a function.
How about if we compromise by switching to functional notation?
That should be easier to read.  That is, instead of this:

  return XFRAME (frame)->buffer_list;

or this:

  return FVAR (XFRAME (frame), buffer_list);

we write this:

  return frame_buffer_list (XFRAME (frame));

Also, instead instead of this:

  f->buffer_list = Fcons (buf, Qnil);

or this:

  FVAR (f, buffer_list) = Fcons (buf, Qnil);

we write this:

  set_frame_buffer_list (f, Fcons (buf, Qnil));

We needn't use capital letters for the functions, since they
can be implemented as true functions (inline, so that the
code is just as fast as before).  This will help readability

Doing this will give us the opportunity to instrument all accesses
to the buffer_list member of frames.  It's a bit more complicated
in the .h file, but it makes the rest of the code easier to read
than FVAR does.

Similarly for WVAR, etc.

reply via email to

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