Michael G Schwern <schw...@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
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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html