Re: [PATCH v9 03/11] ref-filter: implement an `align` atom
- From
Eric Sunshine <sunshine@sunshineco.com>
- Date
- Aug 9, 2015, 08:19 UTC
- Message-ID
- <CAPig+cRoryoJj44D0Q_m3fVAZeYrCc0OiNA7GJ3UtQK4XVOn9g@mail.gmail.com>
- In-Reply-To
- <CAOLa=ZQoHuE_NV1OMQrA7zoqYo6tUvXibURVz+3UknJsNLHV_w@mail.gmail.com>
On Sun, Aug 9, 2015 at 4:09 AM, Karthik Nayak <karthik.188@gmail.com> wrote:
Show 33 quoted lines
> On Sun, Aug 9, 2015 at 1:34 PM, Eric Sunshine <sunshine@sunshineco.com> wrote:
>> On Sun, Aug 9, 2015 at 2:55 AM, Karthik Nayak <karthik.188@gmail.com> wrote:
>>> On Sun, Aug 9, 2015 at 9:12 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:
>>>> That raises another question. Why are 'struct ref_formatting_state',
>>>> 'struct align', 'struct atom_value', etc. defined in ref-filter.h at
>>>> all? Aren't those private implementation details of ref-filter.c, or
>>>> do you expect other code to be using them?
>>>
>>> I guess struct ref_formatting_state and struct align could be moved to
>>> ref-filter.c. About struct atom_value its referenced by ref_array_item()
>>> so any reader reading about this, would find it easier if atom_value()
>>> is at the same place.
>>
>> Do you expect callers ever to be manipulating or otherwise accessing
>> the atom_value of ref_array_item? If callers have no business mucking
>> with atom_value, then one option would be to simply forward declare
>> atom_value in the header:
>>
>> struct atom_value;
>>
>> struct ref_array_item {
>> ...
>> struct atom_value *value;
>> ...
>> };
>>
>> which makes atom_value opaque to clients of ref-filter. The actual
>> declaration of atom_value would then be moved to ref-filter.c, thus
>> kept private.
>
> Also the code that this was done in has been excepted into `next`
> so either I send a new series for the same, or write a patch just to
> move this from ref-filter.h to ref-filter.c. So what would you suggest?To my eye, atom_value seems to encapsulate a bunch of state local to and only meaningful to ref-filter's internal workings, so it doesn't really belong in the public header. Assuming that you don't foresee any callers ever needing to access the properties of atom_value, then it might indeed be reasonable to introduce a patch which moves it from the .h file to the .c file (while leaving only a forward declaration in the .h file).