Michael G Schwern <schwern@xxxxxxxxx> 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. -- 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