On Sun, Aug 9, 2015 at 1:49 PM, Eric Sunshine <sunsh...@sunshineco.com> wrote:
> On Sun, Aug 9, 2015 at 4:09 AM, Karthik Nayak <karthik....@gmail.com> wrote:
>> On Sun, Aug 9, 2015 at 1:34 PM, Eric Sunshine <sunsh...@sunshineco.com>
>> wrote:
>>> On Sun, Aug 9, 2015 at 2:55 AM, Karthik Nayak <karthik....@gmail.com> wrote:
>>>> On Sun, Aug 9, 2015 at 9:12 AM, Eric Sunshine <sunsh...@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).
Thanks! will add it to the series.
--
Regards,
Karthik Nayak
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
