Re: [PATCH 00/30] Read loose references lazily

[Michael Haggerty <mhagger@alum.mit.edu>]

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/