On 1/7/2023 8:48 AM, Jeff King wrote:
> I often get confused about the difference between:
>
> - read_object()
> - read_object_file();
> - read_object_file_extended();
> - repo_read_object_file();
>
> Since Jonathan's recent cleanups from 9e59b38c88 (object-file: emit
> corruption errors when detected, 2022-12-14), these are mostly thin
> wrappers around each other and around oid_object_info_extended().
>
> This series shuffles things around a little more so that we are down to
> just read_object_file() and repo_read_object_file(). And the
> relationship there is pretty easy (and long-term we'd eventually merge
> them once everyone has a repository object).
I read the patches carefully and the translations look correct and
definitely help with this confusing mess of method names.
> It is a net reduction in lines, even though some of the callers end up a
> little longer (because they have to stuff pointers into an object_info
> struct). If that's too distasteful, the middle ground is to have a
> helper like:
>
> void *foo(struct repository *r, const struct object_id *oid,
> enum object_type *type, unsigned long *size,
> unsigned flags)
> {
> struct object_info oi = OBJECT_INFO_INIT;
> void *content;
>
> oi.typep = type;
> oi.sizep = size;
> oi.contentp = ret;
>
> if (oid_object_info_extended(r, oid, &oi, flags) < 0)
> return NULL;
> return content;
> }
>
> which is basically the same as read_object(), but makes it clear that
> you can pass OBJECT_INFO flags. The trouble is that I could not come up
> with a name for it that was not confusing. ;) So just having most places
> call oid_object_info_extended() directly seemed better. It would be nice
> if that function had a shorter name, too, but I left that for another
> day.
I did think that requiring callers to create their own object_info
structs (which takes at least four lines) would be too much, but
the number of new callers is so low that I think this is a fine place
to stop.
Thanks,
-Stolee
