git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 09/13] refs: introduce an iterator interface

From
Michael Haggerty <mhagger@alum.mit.edu>
Date
Jun 3, 2016, 11:48 UTC
Message-ID
<57516E84.6020007@alum.mit.edu>
In-Reply-To
<CAPig+cQte++ngtXdQmpjei9sr+KPKi7qs+vHgijU+Gj1eHDUXQ@mail.gmail.com>
On 06/01/2016 01:12 AM, Eric Sunshine wrote:
Show 29 quoted lines
> On Tue, May 31, 2016 at 3:59 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
>> On 05/31/2016 07:29 AM, Eric Sunshine wrote:
>>> On Mon, May 30, 2016 at 3:55 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
>>>> +struct ref_iterator *empty_ref_iterator_begin(void);
>>>> +
>>>> +/*
>>>> + * Return true iff ref_iterator is an empty_ref_iterator.
>>>> + */
>>>> +int is_empty_ref_iterator(struct ref_iterator *ref_iterator);
>>>
>>> I can see that you used this function as an optimization or
>>> convenience in overlay_ref_iterator_begin(), but do you expect it to
>>> be generally useful otherwise? Is it worth publishing? Do you have
>>> other use-cases in mind?
>>
>> It is only "published" within the refs module, in refs/refs-internal.h.
>> This header file is not meant to be used by code outside of the refs module.
> 
> Ah, I forgot about that. In that case, it's probably less of an issue.
> 
>> My thinking was that it might be useful to other reference backends. The
>> function is pretty safe for anybody to call, though I admit that it is
>> not very general.
>>
>> I don't have a strong feeling either way. If nobody else chimes in, I'll
>> remove it from the header file as you suggested. We can always add it
>> back if somebody needs it.
> 
> I don't feel strongly about it either.
OK then, I'll leave it as-is.
Show 13 quoted lines
>>> Also, can you explain why the merge iterator doesn't also perform the
>>> optimization/convenience of checking if one iterator is an empty
>>> iterator?
>>
>> That's because the merge iterator doesn't know what its select function
>> will do. For example, you could imagine an "intersect" select function
>> that only lets through references that were in *both* sub-iterators. In
>> that case, your suggested "optimization" would be incorrect.
> 
> Makes sense. Thanks for explaining. I wonder if this deserves a
> comment somewhere in code or commit message to make the situation
> clear to a future developer who might think it a good idea to promote
> the "optimization" to the merge iterator.
Good idea. I'll add a comment.
> [...]

Thanks, Michael

Previous: Eric SunshineNext: Junio C Hamano
Message 17 of 27 in “Reference iterators”
  1. 00/13 Reference iteratorsMichael Haggerty, May 30, 2016
  2. 01/13 refs: remove unnecessary "extern" keywordsMichael Haggerty, May 30, 2016
  3. 02/13 do_for_each_ref(): move docstring to the header fileMichael Haggerty, May 30, 2016
  4. 03/13 refs: use name "prefix" consistentlyMichael Haggerty, May 30, 2016
  5. 04/13 delete_refs(): add a flags argumentMichael Haggerty, May 30, 2016
  6. 05/13 remote rm: handle symbolic refs correctlyMichael Haggerty, May 30, 2016
  7. 06/13 get_ref_cache(): only create an instance if there is a submoduleMichael Haggerty, May 30, 2016
  8. 07/13 entry_resolves_to_object(): rename function from ref_resolves_to_object()Michael Haggerty, May 30, 2016
  9. 08/13 ref_resolves_to_object(): new functionMichael Haggerty, May 30, 2016
  10. 09/13 refs: introduce an iterator interfaceMichael Haggerty, May 30, 2016
  11. Ramsay JonesMay 30, 2016
  12. Ramsay JonesMay 30, 2016
  13. Michael HaggertyMay 31, 2016
  14. Eric SunshineMay 31, 2016
  15. Michael HaggertyMay 31, 2016
  16. Eric SunshineMay 31, 2016
  17. Michael HaggertyJun 3, 2016
  18. Junio C HamanoMay 31, 2016
  19. Michael HaggertyMay 31, 2016
  20. Duy NguyenJun 2, 2016
  21. Michael HaggertyJun 2, 2016
  22. 10/13 do_for_each_ref(): reimplement using reference iterationMichael Haggerty, May 30, 2016
  23. 11/13 for_each_reflog(): don't abort for bad referencesMichael Haggerty, May 30, 2016
  24. 12/13 dir_iterator: new API for iterating over a directory treeMichael Haggerty, May 30, 2016
  25. David TurnerJun 1, 2016
  26. Michael HaggertyJun 3, 2016
  27. 13/13 for_each_reflog(): reimplement using iteratorsMichael Haggerty, May 30, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.