From mboxrd@z Thu Jan  1 00:00:00 1970
From: mailings at hupie.com (Ferry Huberts)
Date: Sun, 06 Mar 2011 22:20:05 +0100
Subject: [CGit] [PATCH v2 3/6] new_filter: determine extra_args from	filter
 type
In-Reply-To: <AANLkTimi_36cPi+YySaMMnWKBeggiH+EYACWYKqG2aij@mail.gmail.com>
References: <1299198695-23215-1-git-send-email-mailings@hupie.com>	<1299198695-23215-4-git-send-email-mailings@hupie.com>
 <AANLkTimi_36cPi+YySaMMnWKBeggiH+EYACWYKqG2aij@mail.gmail.com>
Message-ID: <4D73FA85.5070204@hupie.com>

On 03/06/2011 03:50 PM, Lars Hjemli wrote:
> On Fri, Mar 4, 2011 at 01:31, Ferry Huberts <mailings at hupie.com> wrote:
>> -struct cgit_filter *new_filter(const char *cmd, int extra_args)
>> +struct cgit_filter *new_filter(const char *cmd, filter_type filtertype)
>>  {
>>        int i = 0;
>>        struct cgit_filter *f;
>> +       int extra_args;
>>
>>        if (!cmd || !cmd[0])
>>                return NULL;
>>
>> +       switch (filtertype) {
>> +               case SOURCE:
>> +                       extra_args = 1;
>> +                       break;
>> +
>> +               case ABOUT:
>> +               case COMMIT:
>> +               default:
>> +                       extra_args = 0;
>> +                       break;
>> +       }
>> +
> 
> Not sure if I like this since it is the caller who knows how many
> extra args it will need. But the patch avoids duplicate magic numbers,
> so I'll have to think about this one a little more.
> 
> --
> larsh

I did it this way because currently the number of extra arguments is
linked hard to the type of the filter, which is also kind of obvious
since it would be quite confusing to have a different number of
arguments for the same type of filter, depending on the context under
which it is run (unless ofcourse one the parameters would make the
context clear)


-- 
Ferry Huberts