Re: [Emacs-diffs] /srv/bzr/emacs/trunk r109327: Generalize INTERNAL_FIELD between buffers, keyboards and frames.

[Dmitry Antipov <dmantipov@yandex.ru>]

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
   {
     NAME,
     ICON_NAME,
     TITLE
     ...
   };

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.

Dmitry