Re: [PATCH v2 00/10] port branch.c to use ref-filter's printing options
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Oct 9, 2015, 18:29 UTC
- 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:
Show 31 quoted lines
> 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.