Re: [PATCH 0/5] cleaning up read_object() family of functions

From: Derrick Stolee <derrickstolee@github.com>
Date: Jan 11, 2023, 20:17 UTC
Message-ID: <6c896cc8-2da9-a448-4ab6-2dc535fb0e2b@github.com>
In-Reply-To: <Y77/T8dktee3wOA5@coredump.intra.peff.net>

On 1/11/2023 1:26 PM, Jeff King wrote:

Show 13 quoted lines

> On Mon, Jan 09, 2023 at 10:09:32AM -0500, Derrick Stolee wrote:
> 
>> 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.
> 
> Yeah, that was my feeling. I do wonder if there's a way to make it
> easier for callers of oid_object_info_extended(), but I couldn't come up
> with anything that's nice enough to merit the complexity.
> 
> For example, here's an attempt to let the caller use designated
> initializers to set up the query struct:

> +	struct object_info oi = OBJECT_INFO(.typep = type,
> +					    .sizep = size,
> +					    .contentp = &data);

Your macro expansion creates this format:

	struct object_info oi = {
		.type = type,
		.sizep = size,
		.contentp = &data,
	};

And even this expansion looks a bit better than the inline updates:

> -	oi.typep = type;
> -	oi.sizep = size;
> -	oi.contentp = &data;

So maybe that's a preferred pattern that we could establish by replacing the existing callers. It's also such a minor point that I wouldn't say it's a high priority to do.

Thanks, -Stolee