git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Keith Cascio <keith@CS.UCLA.EDU>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Junio C Hamano <gitster@pobox.com>,
	Pierre Habouzit <madcoder@madism.org>,
	git@vger.kernel.org
Subject: Re: [PATCH] Use DIFF_XDL_SET/DIFF_OPT_SET instead of raw bit-masking
Date: Wed, 18 Feb 2009 20:02:46 -0500	[thread overview]
Message-ID: <20090219010246.GD25808@coredump.intra.peff.net> (raw)
In-Reply-To: <alpine.GSO.2.00.0902181437260.6181@kiwi.cs.ucla.edu>

On Wed, Feb 18, 2009 at 02:59:29PM -0800, Keith Cascio wrote:

> Actually I appreciate your feedback, and the more direct the better.
> The chief value I see in revising the code to accomplish these bit
> settings uniformly using well known macros is that later, if someone
> has good reason to extend the macro so it results in some new side
> effect, e.g. to update a dirty bit mask, the new behavior
> automatically cascades to every appropriate use out there in the code.
> A macro is essentially a "code constant".  As with other constants,
> the benefit comes from defining it once and using it everywhere.  Is
> this effect not worth as much as I think it is?  Is there a hidden
> gotcha in my ideal?  Or does anyone else see value here?  Please speak
> up!

I think you are running into "if it's not broken, don't fix it".  That
is, there is a transaction cost to making changes to the code. It can be
as small a cost as "now somebody working in a related area has a
conflict (even if textual) and has to spend time resolving". Or it can
be as big as "you introduced new bugs".  In this case, I think any costs
would tend towards the former and not the latter.

That cost has to be weighed against the benefit.

The usual attitude in git is that minor cleanups or enhancements like
this should be coupled with patches that build on them. Saying "this
might help in the future if somebody does X" means you are paying the
cost now, but there may or may not ever _be_ any benefit.

In this case, I think there are actually two changes in your patch:

  1. consistently using DIFF_OPT_* macros, which are used in 99% of
     callsites already

  2. adding and using DIFF_XDL macros

I think (1) has immediate value. Anyone looking at the code and seeing
the existence of DIFF_OPT macros and how commonly they are used might
think they are used exclusively. And that means it is easy to miss
callsites when searching through the code. So to me, making things
consistent brings value.

For (2), that situation does not exist, since you are introducing new
macros.

Personally, I don't mind the abstraction layer of the XDL macros,
especially since they match the style of the existing DIFF_OPT macros
(and the only reason they are not in the DIFF_OPT bitfield at all is
that they must be passed separately to xdiff).

-Peff

      reply	other threads:[~2009-02-19  1:04 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-17  3:26 [PATCH] Use DIFF_XDL_SET/DIFF_OPT_SET instead of raw bit-masking Keith Cascio
2009-02-17 12:05 ` Johannes Schindelin
2009-02-17 17:33   ` Keith Cascio
2009-02-17 22:57     ` Johannes Schindelin
2009-02-18 20:52       ` Keith Cascio
2009-02-18 21:22         ` Johannes Schindelin
2009-02-18 22:59           ` Keith Cascio
2009-02-19  1:02             ` Jeff King [this message]

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=20090219010246.GD25808@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=keith@CS.UCLA.EDU \
    --cc=madcoder@madism.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).