From: Junio C Hamano <gitster@pobox.com>
Date: Fri, 09 Oct 2015 18:29:05 GMT
Subject: Re: [PATCH v2 00/10] port branch.c to use ref-filter's printing options
Message-ID: <xmqqfv1jq4jy.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <vpqpp0ojvs6.fsf@grenoble-inp.fr>

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>
>> Then used_atom[] could become something like
>>
>>     struct {
>>     	const char *str; /* e.g. "align:position=left,32" */
>> 	struct {
>>         	const char *part0; /* everything before '=' */
>>                 const char *part1; /* optional */
>> 	} *modifier;
>>         int modifier_nr;
>>     } *used_atom;
>
> If the goal is to prepare as much as possible when parsing the format
> string, I'd even push it one step further and have stg like
>
>      struct {
>      	const char *str; /* e.g. "align:position=left,32" */
>  	union {
>          	struct {
> 			int position;
> 			enum { left, right, center } kind;
> 		} align;
>                 struct {
>                 	....;
>                 } objectname;
>         int modifier_nr;
>      } *used_atom;
>
> Just a thought, I'm not sure how useful this would be, and this may be
> too much change for this series (so it may deserve a separate topic).

Yes, if we are willing to enrich the element of valid_atom[] array
with a type-specific parsing functions, we could even do that.  Then
populate_value() would not have to do any parsing and just do the
filling.

I was shooting for a middle ground, but certainly with an eye
towards such an endgame state in the future.