Re: [PATCH v3 04/14] object-file: introduce function to iterate through objects

[Taylor Blau <me@ttaylorr.com>]

On Thu, Jan 22, 2026 at 07:52:00AM +0100, Patrick Steinhardt wrote:
> > I think if there were multiple ways to iterate over loose objects, it
> > makes a lot of sense to prefix them such that they are grouped to avoid
> > mixing interfaces or using one API when you meant to call another. But
> > my understanding is that the intent here is to consolidate all of the
> > different ways to iterate over objects which live in different
> > odb_source implementations opaque to the caller. As a result, what other
> > way exists to iterate over loose objects?
>
> There will be more to come: iterating over objects with a prefix, for
> example. In general, this series is taking a layered approach:
>
>   - `odb_for_each_object()` is the high-level function that users should
>     use if possible. It is part of the ODB layer and abstracts away
>     details about the ODB sources.
>
>   - `odb_source_for_each_object()` will be introduced in the next patch
>     series. It allows the user to take an ODB source and iterate over
>     its contained objects, regardless of what the backend is.
>
>   - `odb_source_loose_for_each_object()` is the low-level implementation
>     for one specific backend. We also have equivalent functions for the
>     other backends, like for example for packed objects.
>
> The longer the function name, the more specific the logic becomes. Sure,
> eventually it becomes a mouthful, but ideally users wouldn't have to
> ever interact with the low-level details at all.

Thanks for the extra information, this is definitely what I was missing.
If there are many ways to iterate over objects, then the naming scheme
above makes sense.

The point that I was trying to get across was that I think that the
convention of naming a function that does "foo" to a struct "S" as
"S_foo()" is great, but that we shouldn't apply that convention when
there is only one way to do "foo" in general.

For this particular case, I think I would have pushed back if you said
that `odb_for_each_object()` was the only function that we'd end up with
(i.e., there is no non-ODB way to do this, so for_each_object() is just
as descriptive IMO). But that's not the case, so I think the naming
scheme you have here makes sense.

Thanks,
Taylor