Derrick Stolee <derrickstolee@xxxxxxxxxx> writes:
> My current workaround is to define the size of the array in the
> header file:
>
> ---
>
> enum ref_namespace {
> NAMESPACE_HEAD,
> NAMESPACE_BRANCHES,
> NAMESPACE_TAGS,
> NAMESPACE_REMOTE_REFS,
> NAMESPACE_STASH,
> NAMESPACE_REPLACE,
> NAMESPACE_NOTES,
> NAMESPACE_PREFETCH,
> NAMESPACE_REWRITTEN,
>
> /* Must be last */
> NAMESPACE__COUNT
> };
>
> /* See refs.c for the contents of this array. */
> extern struct ref_namespace_info ref_namespaces[NAMESPACE__COUNT];
Because there is no reason why we want to keep the size of the array
opaque in this particular case, it may even be preferrable over the
original ref_namespace[] array of unspecified size. Nice.
BTW, I prefer to name my arrays with a singular noun, when the
predominant use of it in the code that is an API customer is to name
an individual element and use it.
In this case, many API users do things like
ref_namespace[NAMESPACE_NOTES}.ref = ...;
so a singular name would be more appropriate. thing[4] that means
the fourth thing feels more intuitive than things[4], at least to
me.
On the other hand, when API customers mostly pass the whole thing
around as an almost opaque collection to the API function, then a
plural name is more appropriate. The reason why I focus on API
customers is because API implementation of course has to go in to
each individual element of the array and work on it at some level,
and "individual access means singular name" rule would become non
workable. The names are mostly to help API customers, so if an
array is perceived by them as mostly a collection of things, then
naming it in plural would make it more natural.
