Re: Fix git-svn for SVN 1.7

[Eric Wong <normalperson@yhbt.net>]

Michael G Schwern <schwern@pobox.com> wrote:
> On 2012.7.30 3:15 PM, Eric Wong wrote:
> >> Right now, canonicalization is a bug generator.  Paths and URLs have to be in
> >> the same form when they're compared.  This requires meticulous care on the
> >> part of the coder and reviewer to check every comparison.  It scatters the
> >> logic for proper comparison all over the code.  Redundant logic scattered
> >> around the code is a Bad Thing.  It makes it more likely a coder will forget
> >> the logic, or get it wrong, and a human reviewer must be far more vigilant.
> > 
> > <snip>  I agree completely with canonicalization.
> 
> Sorry, I'm not sure what you're agreeing with.

That's it's a bug generator and we shouldn't have redundant logic.
Having functions to compare objects themselves is a good thing.

> >> The only downside is when chasing down a bug related to canonicalization one
> >> might have to realize that eq is overloaded.
> > 
> > Having to realize eq is overloaded is a huge downside to me.
> 
> Presumably you'd be reviewing the change which implements the overloaded
> objects, so you'd know about it.  And it would be documented.

The change itself is easy to review.   Picking up the code a few
months/years down the line and having to know "eq" is overloaded
tends to bite people.

> I've listed a bunch of concrete positives for using comparison overloaded
> URI/path objects vs how it's currently being done.  How about you voice some
> of the downsides in concrete terms?  Or an alternative that solves the current
> problems?

Any custom comparison function would do the trick (e.g. URI::eq()).

I _want_ URI/path objects.  I do not want a bare "eq" operator to
obscure the fact it's calling URI::eq() behind-the-scenes.

That said, I don't mind overloads when it's obvious an overload is being
used (e.g. stringify).  It's things like "eq" which obscure the fact
function calls are happening in the background.