On 04/25/2012 08:39 PM, Junio C Hamano wrote:
mhagger@xxxxxxxxxxxx writes:
From: Michael Haggerty<mhagger@xxxxxxxxxxxx>
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@xxxxxxxxxxxx
http://softwareswirl.blogspot.com/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html