Re: [PATCH 2/2] [GSOC][RFC] ref-filter: introduce enum atom_type
From: ZheNing Hu <hidden>
Date: 2021-05-09 13:45:18
Junio C Hamano [off-list ref] 于2021年5月9日周日 下午4:26写道:
Christian Couder [off-list ref] writes:quoted
I am not sure it's worth having an atom_type field for each valid_atom element if the value of that field is already the index of the element, because then one would always be able to replace `valid_atom[i].atom_type` with just `i`. Or is it for some kind of type safety issue?quoted
I wonder if the enum should be instead defined like this: enum atom_type { ATOM_UNKNOWN = 0, ATOM_REFNAME, ... ATOM_ELSE, ATOM_INVALID, /* should be last */ }; As a struct containing an atom_type would typically be initialized with 0 after being allocated, `ATOM_UNKNOWN = 0` could ensure that we can easily distinguish such a struct where the atom_type is known from such a struct where it is unknown yet. Having ATOM_INVALID as always the last enum value (even if some new ones are added later) could help us iterate over the valid atoms using something like: for (i = ATOM_UNKNOWN + 1; i < ATOM_INVALID; i++) /* do something with valid_atom[i] */;OK. As to "safety", I think it still makes sense to declare "enum", but I agree that we do not necessarily have to have it in the valid_atom[] struct. We could do something like this instead: static struct { const char *name; info_source source; cmp_type cmp_type; int (*parser)(const struct ref_format *format, struct used_atom *atom, const char *arg, struct strbuf *err); } valid_atom[] = { [ATOM_REFNAME] = { "refname", SOURCE_NONE, FIELD_STR, refname_atom_parser }, [ATOM_OBJECTTYPE] = { "objecttype", SOURCE_OTHER, FIELD_STR, objecttype... [ATOM_OBJECTSIZE] = { "objectsize", SOURCE_OTHER, FIELD_ULONG, objectsi... ...
Thank! Good suggection. We hope that the atom_type and valid_atom items establish a clear connection. Maybe we should add some comments before the definition of the `enum atom_type` to remind the coder of the connection between atom_type and valid_atom. -- ZheNing Hu