Re: Is it time to remove INTERNAL_FIELD?

[Eli Zaretskii]

> From: Oleh Krehel <address@hidden>
> Cc: address@hidden,  address@hidden
> Date: Thu, 23 Apr 2015 18:32:17 +0200
> 
> Why is it preferred to type BVAR (foo, name) instead of foo->name?

Because it will then be easy to change the definition of BVAR into
something less trivial.  E.g., imagine this alternative:

 #define BVAR(buf, field) ((buf)->thread_storage (current_thread)->(field))

Or whatever, I hope you get the point.

> 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.

Using accessors has its downsides, yes.  It makes the object more
opaque.  Perhaps Semantic should become smarter about this.  But you
aren't saying that accessors should not be used, are you?

> >> 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.

You have been lucky.  In general, when you work with C++ libraries to
which you have no sources, you can never know what the overloaded
operators do, or how expensive they are.