Stefan Beller [off-list ref] writes:
// Note: git_attr_check_elem seems to be useless now, as the
// results are not stored in there, we only make use of the `attr` key.
I do not think git_attr_check_elem would be visible to the callers,
once we split the "inquiry" and "result" like the code illustrated
above. I actually doubt that the type would even internally need to
survive such a rewrite.
The point of "future-proofing" the callers is to hide such
implementation details from them. We know that the current API will
need to be updated at least once to prepare the implementation of
the API so that it has some chance of becoming thread-safe, and I
think we know enough how the updated API should look like to the
callers. I was hoping the minimum future-proofing would allow us to
update the current "attr" API users only once, without having to
update them again when we make it ready to be used in threaded
environment.
On Mon, Oct 3, 2016 at 2:56 PM, Junio C Hamano [off-list ref] wrote:
Stefan Beller [off-list ref] writes:
quoted
// Note: git_attr_check_elem seems to be useless now, as the
// results are not stored in there, we only make use of the `attr` key.
I do not think git_attr_check_elem would be visible to the callers,
once we split the "inquiry" and "result" like the code illustrated
above. I actually doubt that the type would even internally need to
survive such a rewrite.
So how would we go about git_all_attrs then?
I think those (only builtin/check-attr.c as well as Documentation) would
need to read these names off of git_attr_check_elem.
So instead we could do a
int git_all_attrs(const char *path, char *result_keys[], char *result_values[],
int nr, int alloc)
Internally git_all_attrs would use nr/alloc to resize result_{key,value} to an
appropriate size and then fill it with keys/values.
Although I do not think check-attr needs to be fast as it is a debugging
tool rather than a daily used tool, but it would fit into the current
line of thinking?
The point of "future-proofing" the callers is to hide such
implementation details from them. We know that the current API will
need to be updated at least once to prepare the implementation of
the API so that it has some chance of becoming thread-safe, and I
think we know enough how the updated API should look like to the
callers.
I don't think we have the same idea how it should look like, as e.g.
it is unclear what we do with the `const struct git_attr` in the
git_attr_check to me.
I was hoping the minimum future-proofing would allow us to
update the current "attr" API users only once, without having to
update them again when we make it ready to be used in threaded
environment.
Ok, so let's first define how the future proofed API should look like
and then we can go towards it.