Re: Is it time to remove INTERNAL_FIELD?

[Oleh Krehel]

Eli Zaretskii <address@hidden> writes:
>> [...]
>> I'm totally fine with this:
>>
>>     INLINE void
>>     kset_last_kbd_macro (struct kboard *kb, Lisp_Object val)
>>     {
>>       kb->Vlast_kbd_macro_ = val;
>>     }
>>
>> just as I'm fine with this:
>>
>>     INLINE void
>>     kset_last_kbd_macro (struct kboard *kb, Lisp_Object val)
>>     {
>>       kb->Vlast_kbd_macro = val;
>>     }
>
> We are talking past each other.  I wasn't talking about
> kset_last_kbd_macro etc, I was talking about expressions that
> explicitly mention field names.  Like this one:
>
>   foo->name = bar;
>
> or this:
>
>   BVAR (foo, name) = bar;
>
> or this:
>
>   buffer_name = BVAR (foo, name);
>
> It's the "name" part that I care about.
>
> If "BVAR (foo, name)" expands into "foo->name_", then no code can use
> bar->name anywhere without triggering a compilation error.  But I, as
> code write, can still call the field "name" and use it in my code, and
> have the preprocessor append the underscore for me.

Why is it preferred to type BVAR (foo, name) instead of foo->name?
This confuses me, because I can't use Semantic to assist me in what I'm
doing. For instance, starting with:

    kb->Vw

Semantic can tell me that the only possible completions are Vwindow_list
and Vwindow_system. This is great for someone who's new, because I see
what options are available to me. This is also great for someone who's
experienced, because it still acts as a spell checker and speeds up
coding. I can't get the same benefits for:

    kb->INTERNAL_FIELD (Vwindow_system) = val;

The first variant of the code feels like I'm in control of the code, and
I'm actually dealing with code.

The second variant feels like I'm doing incantations, keeping fingers
crossed that it works, and actually dealing with text and not with code.

>> It's not obvious how simple or intricate INTERNAL_FIELD is or what it
>> does. At the first glance, looks like C++ member function call.
>
> And what's wrong with that?  For someone who programs in C++, and
> should therefore be ready to accept overloaded operators that can
> compute the end of the world as part of their processing, how do you
> know, in C++, that "->" is not overloaded to do just that?

The kind of C++ libraries that I'm dealing with overload arithmetic
operators on vectors and matrices, actually simplifying the code.
INTERNAL_FIELD simply does string substitution. That's not immensely
useful and it hampers completion and introspection.

Oleh