[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: Dmitry Antipov
Subject: Re: [Emacs-diffs] /srv/bzr/emacs/trunk r109327: Generalize INTERNAL_FIELD between buffers, keyboards and frames.
Date: Sun, 05 Aug 2012 18:59:10 +0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120713 Thunderbird/14.0

On 08/03/2012 10:58 PM, Paul Eggert 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.

Why this is a problem ever? OK, maybe AREF and ASET are better;
but the only way to implement FVARs as functions is to have
array of Lisp_Objects in struct frame and meaningful indexes
for the particular slots, i.e.

enum frame_slots

I don't like this, and most probably others will not like it too.

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));

IMHO this is just a poor copy of C++ class :-(:
if you have a huge class with 50 private members, you're
enforced to have 50 get_xxx and 50 set_xxx member functions.
Most of them are inline and fast, but, (IMHO again) they
do not improve readability and makes sense only if you have
a huge class hierarchies where the fine-granted member access
control is very important for some another reason.


reply via email to

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