Re: Is it time to remove INTERNAL_FIELD?

[Oleh Krehel]

Eli Zaretskii <address@hidden> writes:

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

OK, fine. At least it's possible to cook up a viable heuristic for
completing BVAR with Semantic, because it has the semantics of accessing
the buffer object. INTERNAL_FIELD is just mental arithmetic, it doesn't
do anything. It's possible to make a heuristic for it as well, but I
like to see it removed instead.

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

I like accessors for C++, but I'm not really familiar with large scale C
programming. Are macros really the state-of-the-art for making
accessors?

Oleh