All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Haggerty <mhagger@alum.mit.edu>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Jeff King <peff@peff.net>,
	Jakub Narebski <jnareb@gmail.com>,
	Heiko Voigt <hvoigt@hvoigt.net>,
	Johan Herland <johan@herland.net>
Subject: Re: [PATCH 00/30] Read loose references lazily
Date: Thu, 26 Apr 2012 23:33:58 +0200	[thread overview]
Message-ID: <4F99BF46.9050501@alum.mit.edu> (raw)
In-Reply-To: <xmqqbomfd5bt.fsf@junio.mtv.corp.google.com>

On 04/25/2012 08:39 PM, Junio C Hamano wrote:
> mhagger@alum.mit.edu writes:
>
>> From: Michael Haggerty<mhagger@alum.mit.edu>
>>
>> Patches 10 - 25 mostly switch a lot of code from using ref_dir
>> pointers to using ref_entry pointers as arguments and return values.
>> This is important, because ...
>
> The earlier parts looked sane, but the ref_dir set of patches looked
> like merely working around the fact that "struct ref_dir" does not have
> the name field and you had to upcast it to ref_entry to access the full
> name.

Yes, that plus the fact that the ref_entry::flag field is needed in 
ref_entry (to distinguish between value and directory entries) but also 
to interpret the contents of the ref_value / ref_dir.

> All the places that used to take ref_dir never wanted to get an entry
> that represents a leaf node (i.e. ref_value kind of ref_entry), but now
> because you made everybody to take ref_entry, the resulting code is much
> more error prone and the static type checking done by the compiler helps
> us much less when updating the code.  It can already be seen that you
> had to sprinkle a lot of assert(flag&  REF_DIR), but at runtime in
> non-debug build that will become no-op and it is not a substitute for
> the static type checking we used to have.
>
> Can't we approach this differently so that we can keep the type safety?

Thanks for this comment.  I've obviously been ruined by OO languages, in 
which [name + flag + struct ref_value] and [name + flag + struct 
ref_dir] (which *are* useful combinations of data) would be subclasses, 
and the downcasting from ref_entry would only have to occur in only one 
place, while the compiler could guarantee consistency everywhere else.

In C, I don't see a way to implement the equivalent semantics that is 
less annoying than the code that I submitted.

But since [name + flag + struct ref_value] and [name + flag + struct 
ref_dir] never leave the library as structs, it is indeed possible to 
write the code in a different way that leaves most functions working 
with ref_dir instead of having to use ref_entry everywhere.  I have 
implemented this and will submit it shortly.

Thanks again for your suggestion; the resulting code is indeed simpler.

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/

      reply	other threads:[~2012-04-26 21:34 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-24 22:45 [PATCH 00/30] Read loose references lazily mhagger
2012-04-24 22:45 ` [PATCH 01/30] get_ref_dir(): return early if directory cannot be read mhagger
2012-04-24 22:45 ` [PATCH 02/30] get_ref_dir(): use a strbuf to hold refname mhagger
2012-04-24 22:45 ` [PATCH 03/30] get_ref_dir(): rename "base" parameter to "dirname" mhagger
2012-04-24 22:45 ` [PATCH 04/30] get_ref_dir(): require that the dirname argument ends in '/' mhagger
2012-04-24 22:45 ` [PATCH 05/30] refs.c: extract function search_for_subdir() mhagger
2012-04-24 22:45 ` [PATCH 06/30] get_ref_dir(): take the containing directory as argument mhagger
2012-04-24 22:45 ` [PATCH 07/30] do_for_each_reflog(): return early on error mhagger
2012-04-24 22:45 ` [PATCH 08/30] do_for_each_reflog(): use a strbuf to hold logfile name mhagger
2012-04-24 22:45 ` [PATCH 09/30] do_for_each_reflog(): reuse strbuf across recursive function calls mhagger
2012-04-24 22:45 ` [PATCH 10/30] refs: wrap top-level ref_dirs in ref_entries mhagger
2012-04-26 14:38   ` Michael Haggerty
2012-04-24 22:45 ` [PATCH 11/30] get_packed_refs(): return (ref_entry *) instead of (ref_dir *) mhagger
2012-04-24 22:45 ` [PATCH 12/30] get_loose_refs(): " mhagger
2012-04-24 22:45 ` [PATCH 13/30] is_refname_available(): take " mhagger
2012-04-24 22:45 ` [PATCH 14/30] find_ref(): " mhagger
2012-04-24 22:45 ` [PATCH 15/30] read_packed_refs(): " mhagger
2012-04-24 22:45 ` [PATCH 16/30] add_ref(): " mhagger
2012-04-24 22:45 ` [PATCH 17/30] find_containing_direntry(): use " mhagger
2012-04-24 22:45 ` [PATCH 18/30] get_ref_dir(): take " mhagger
2012-04-24 22:45 ` [PATCH 19/30] get_ref_dir(): remove dirname argument mhagger
2012-04-24 22:45 ` [PATCH 20/30] search_for_subdir(): take (ref_entry *) instead of (ref_dir *) mhagger
2012-04-24 22:45 ` [PATCH 21/30] search_ref_dir(): " mhagger
2012-04-24 22:45 ` [PATCH 22/30] add_entry(): " mhagger
2012-04-24 22:45 ` [PATCH 23/30] do_for_each_ref_in_dirs(): " mhagger
2012-04-24 22:45 ` [PATCH 24/30] do_for_each_ref_in_dir(): " mhagger
2012-04-24 22:45 ` [PATCH 25/30] sort_ref_dir(): " mhagger
2012-04-24 22:45 ` [PATCH 26/30] struct ref_dir: store a reference to the enclosing ref_cache mhagger
2012-04-24 22:45 ` [PATCH 27/30] read_loose_refs(): rename function from get_ref_dir() mhagger
2012-04-24 22:45 ` [PATCH 28/30] read_loose_refs(): access ref_cache via the ref_dir field mhagger
2012-04-24 22:45 ` [PATCH 29/30] create_dir_entry(): allow the flag value to be passed as an argument mhagger
2012-04-25 18:31   ` Junio C Hamano
2012-04-25 18:52     ` Junio C Hamano
2012-04-26 21:12       ` Michael Haggerty
2012-04-24 22:45 ` [PATCH 30/30] refs: read loose references lazily mhagger
2012-04-25 18:39 ` [PATCH 00/30] Read " Junio C Hamano
2012-04-26 21:33   ` Michael Haggerty [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F99BF46.9050501@alum.mit.edu \
    --to=mhagger@alum.mit.edu \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=hvoigt@hvoigt.net \
    --cc=jnareb@gmail.com \
    --cc=johan@herland.net \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.