From: Eric Wong <normalperson@yhbt•net>
To: Michael G Schwern <schwern@pobox•com>
Cc: git@vger•kernel.org, gitster@pobox•com, robbat2@gentoo•org,
bwalton@artsci•utoronto.ca, jrnieder@gmail•com
Subject: Re: Fix git-svn for SVN 1.7
Date: Tue, 31 Jul 2012 02:18:18 +0000 [thread overview]
Message-ID: <20120731021816.GA12640@dcvr.yhbt.net> (raw)
In-Reply-To: <50172F10.2030402@pobox.com>
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.
next prev parent reply other threads:[~2012-07-31 2:18 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-28 9:47 Fix git-svn for SVN 1.7 Michael G. Schwern
2012-07-28 9:47 ` [PATCH 1/8] SVN 1.7 will truncate "not-a%40{0}" to just "not-a" Michael G. Schwern
2012-07-28 14:16 ` Jonathan Nieder
2012-07-28 19:32 ` Michael G Schwern
2012-10-09 8:41 ` [PATCH/RFC] svn test: escape peg revision separator using empty peg rev Jonathan Nieder
2012-10-09 9:47 ` Michael J Gruber
2012-10-09 10:19 ` Jonathan Nieder
2012-10-10 20:37 ` Eric Wong
2012-10-10 21:02 ` Jonathan Nieder
2012-10-10 21:31 ` Eric Wong
2012-10-10 21:42 ` Jonathan Nieder
2012-10-10 22:16 ` Eric Wong
2012-10-10 22:33 ` Junio C Hamano
2012-07-28 9:47 ` [PATCH 2/8] Fix typo in test Michael G. Schwern
2012-07-28 9:47 ` [PATCH 3/8] Improve our URL canonicalization to be more like SVN 1.7's Michael G. Schwern
2012-07-28 9:47 ` [PATCH 4/8] Replace hand rolled URL escapes with canonicalization Michael G. Schwern
2012-07-28 9:47 ` [PATCH 5/8] Canonicalize earlier in a couple spots Michael G. Schwern
2012-07-28 9:47 ` [PATCH 6/8] Add function to append a path to a URL Michael G. Schwern
2012-07-28 9:47 ` [PATCH 7/8] Turn on canonicalization on newly minted URLs Michael G. Schwern
2012-10-06 19:24 ` [PATCH/RFC] test: work around SVN 1.7 mishandling of svn:special changes Jonathan Nieder
2012-10-09 10:12 ` [PATCH/RFC v2] git svn: " Jonathan Nieder
2012-10-10 20:11 ` Eric Wong
2012-10-10 20:47 ` [PATCH v3] " Jonathan Nieder
2012-07-28 9:47 ` [PATCH 8/8] Remove some ad hoc canonicalizations Michael G. Schwern
2012-07-30 20:38 ` Fix git-svn for SVN 1.7 Eric Wong
2012-07-30 21:10 ` Michael G Schwern
2012-07-30 22:15 ` Eric Wong
2012-07-31 1:04 ` Michael G Schwern
2012-07-31 2:18 ` Eric Wong [this message]
2012-07-31 4:30 ` Michael G Schwern
2012-07-31 6:53 ` Junio C Hamano
2012-07-31 9:54 ` Michael G Schwern
2012-07-31 20:01 ` Eric Wong
2012-07-31 23:05 ` Junio C Hamano
2012-07-31 23:28 ` Michael G Schwern
2012-07-31 23:24 ` Michael G Schwern
2012-08-01 21:30 ` Eric Wong
2012-08-02 10:31 ` Eric Wong
2012-08-02 16:07 ` Jonathan Nieder
2012-08-02 18:58 ` Junio C Hamano
2012-08-02 19:50 ` Robin H. Johnson
2012-08-02 22:10 ` Eric Wong
2012-08-21 4:04 ` Junio C Hamano
2012-08-21 21:03 ` Eric Wong
2012-08-21 21:34 ` Junio C Hamano
2012-08-02 20:51 ` Eric Wong
2012-08-02 21:22 ` Junio C Hamano
2012-08-02 21:42 ` Eric Wong
2012-08-02 21:55 ` Eric Wong
2012-08-02 22:05 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120731021816.GA12640@dcvr.yhbt.net \
--to=normalperson@yhbt$(echo .)net \
--cc=bwalton@artsci$(echo .)utoronto.ca \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
--cc=jrnieder@gmail$(echo .)com \
--cc=robbat2@gentoo$(echo .)org \
--cc=schwern@pobox$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox