Re: [PATCH 5/9] Refactor excluded and path_excluded
- From
Adam Spiers <git@adamspiers.org>
- Date
- Sep 6, 2012, 17:42 UTC
- Message-ID
- <CAOkDyE8pLO3MKVhtW5WEAmqMROV-QKrMOJHN7JKvwYNy7VgFiQ@mail.gmail.com>
- In-Reply-To
- <CACsJy8CoBvxg9SWFFXbuDJM7Lu74Jw6LVc=7cNwu24h7pijeXQ@mail.gmail.com>
On Thu, Sep 6, 2012 at 4:05 PM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
Show 20 quoted lines
> On Thu, Sep 6, 2012 at 9:59 PM, Thiago Farina <tfransosi@gmail.com> wrote: >> On Thu, Sep 6, 2012 at 9:13 AM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote: >>> On Thu, Sep 6, 2012 at 10:21 AM, Junio C Hamano <gitster@pobox.com> wrote: >>>> Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes: >>>> >>>>> We could introduce exclude_path() and kill path_excluded() then. There >>>>> are just about 5-6 call sites to replace. >>>> >>>> The name path_excluded(... path ...) sounds like it is asking a >>>> yes/no question "is this path excluded?", which actually is what is >>>> going on. >>>> >>>> The name exclude_path(... path ...) sounds as if you are requesting >>>> somebody to exclude the path. Does that meaning match the semantics >>>> of the function? >>> >>> I'm not great at naming. And path_excluded() cannot be reused to avoid >>> problems with other ongoing series if any. So path_is_excluded()? >> >> is_path_excluded()?
It makes me happy to see this suggestion :-) Because this is the exact name I changed it to in an earlier version of my patch series. But then I got worried that a) it did not fit the `foo_1' convention which already seemed to be in use, and b) people would complain about API changes. So I changed it back. However if you would prefer to rename the functions for clarity, then I have more suggestions:
old new ----------------------------------------------------------- path_excluded is_path_excluded excluded is_excluded excluded_from_list is_excluded_from_list path_excluded_1 last_exclude_matching_path excluded_1 last_exclude_matching excluded_from_list_1 last_exclude_matching_from_list