git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v9 03/11] ref-filter: implement an `align` atom

From
Karthik Nayak <karthik.188@gmail.com>
Date
Aug 9, 2015, 12:54 UTC
Message-ID
<CAOLa=ZTJ0k9zbMK-L0sB49X2+DmnLSV-m+4MiPirTbU8r1iOqg@mail.gmail.com>
In-Reply-To
<CAPig+cRoryoJj44D0Q_m3fVAZeYrCc0OiNA7GJ3UtQK4XVOn9g@mail.gmail.com>
On Sun, Aug 9, 2015 at 1:49 PM, Eric Sunshine <sunshine@sunshineco.com> wrote:
Show 42 quoted lines
> On Sun, Aug 9, 2015 at 4:09 AM, Karthik Nayak <karthik.188@gmail.com> wrote:
>> 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).
Thanks! will add it to the series.
-- 
Regards,
Karthik Nayak
Previous: Eric SunshineNext: Eric Sunshine
Message 9 of 13 in “ref-filter: implement an `align` atom”
  1. 03/11 ref-filter: implement an `align` atomKarthik Nayak, Aug 5, 2015
  2. Eric SunshineAug 7, 2015
  3. Karthik NayakAug 8, 2015
  4. Eric SunshineAug 9, 2015
  5. Karthik NayakAug 9, 2015
  6. Eric SunshineAug 9, 2015
  7. Karthik NayakAug 9, 2015
  8. Eric SunshineAug 9, 2015
  9. Karthik NayakAug 9, 2015
  10. Eric SunshineAug 7, 2015
  11. Karthik NayakAug 8, 2015
  12. Matthieu MoyAug 9, 2015
  13. Karthik NayakAug 9, 2015

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.