From: Junio C Hamano <gitster@pobox.com>
To: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Cc: git@vger.kernel.org, Jakub Narebski <jnareb@gmail.com>,
Petr Baudis <pasky@suse.cz>
Subject: Re: [PATCHv2ter 2/2] gitweb: clean up gitweb_check_feature() calls
Date: Sat, 29 Nov 2008 12:39:55 -0800 [thread overview]
Message-ID: <7vej0u1d2c.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <1227959616-8056-1-git-send-email-giuseppe.bilotta@gmail.com> (Giuseppe Bilotta's message of "Sat, 29 Nov 2008 12:53:36 +0100")
Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
> Since gitweb_check_feature now returns a scalar, the parentheses around
> the variables initialized from gitweb_check_feature() are not needed.
Here is what I think the commit message of your [1/2] should have read:
Subject: [PATCH] gitweb: make gitweb_check_feature a boolean wrapper
The gitweb_check_feature() function retrieves the configuration
parameters for the feature (such as the list of snapshot formats or
the list of additional actions), but it is very often used to see if
feature is enabled (which is returned as the first element in the
list).
Because accepting the returned list in a scalar context by mistake
yields the number of elements in the array, which is non-zero in all
cases, such a mistake would result in a bug for the latter use, with
disabled features appearing enabled. All existing callers that call
the function for this purpose assign the return value in the list
context to retrieve the first element, but this is a bug waiting to
happen for future callers that are not careful.
This changes gitweb_check_feature() to a wrapper that can be called
safely in the scalar context to see if a feature is enabled to reduce
the risk of future bugs. A new function gitweb_get_feature() is
introduced for the callers that want the list of configuration
parameters. All existing callers of gitweb_check_feature() that want
the configuration parameters are adjusted to call gitweb_get_feature().
Notice the difference in the tone from your [1/2]. The change is not
about fixing (your proposed commit log message read "gitweb:fixes to
gitweb feature check code") as nothing is broken. It is purely about
futureproofing and I think we should mark it as such.
The splitting of two patches is not strictly necessary, but if you wanted
to, I would do so slightly differently:
* Make [1/2] purely the rename of s/check/get/, saying "the function is
not just checking if it is enabled, but it is getting the configuration
parameter list. I'll introduce a new API to ask if it is enabled,
which will be called 'check', hence this rename".
Obviously, after applying this patch, there should be no caller of
"check".
* Make [2/2] introduce the "check" wrapper, and change the existing
callers of "get" that want boolean to call "check" (and in the scalar
context, as it does not matter anymore). You can steal most of the
above rewrite as your commit message for this (except for the last two
sentences).
Also I would rewrite the mysterious "Comfort code" comment like this:
# A wrapper to check if a given feature is enabled.
# With this, you can say
#
# my $bool_feat = gitweb_check_feature('bool_feat');
# gitweb_check_feature('bool_feat') or somecode;
#
# instead of
#
# my ($bool_feat) = gitweb_get_feature('bool_feat');
# (gitweb_get_feature('bool_feat'))[0] or somecode;
(you also had a few typos in these four example calls).
next prev parent reply other threads:[~2008-11-29 20:41 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-28 20:39 [PATCHv2 0/2] fixes to gitweb feature check code Giuseppe Bilotta
2008-11-28 20:39 ` [PATCHv2 1/2] gitweb: " Giuseppe Bilotta
2008-11-28 20:39 ` [PATCHv2 2/2] gitweb: clean up git_check_feature() calls Giuseppe Bilotta
2008-11-29 11:15 ` [PATCHv2 2/2] gitweb: clean up gitweb_check_feature() calls Giuseppe Bilotta
2008-11-29 11:18 ` Jakub Narebski
2008-11-29 11:53 ` [PATCHv2ter " Giuseppe Bilotta
2008-11-29 20:39 ` Junio C Hamano [this message]
2008-11-29 21:00 ` Junio C Hamano
2008-11-29 21:12 ` [PATCH 2/3] gitweb: rename gitweb_check_feature to gitweb_get_feature Junio C Hamano
2008-11-29 21:16 ` [PATCH 3/3] gitweb: make gitweb_check_feature a boolean wrapper Junio C Hamano
2008-11-29 22:27 ` Giuseppe Bilotta
2008-11-30 0:23 ` Junio C Hamano
2008-11-30 1:31 ` Giuseppe Bilotta
2008-11-29 22:16 ` [PATCHv2ter 2/2] gitweb: clean up gitweb_check_feature() calls Giuseppe Bilotta
2008-11-29 22:26 ` Junio C Hamano
2008-11-29 22:36 ` Jakub Narebski
2008-11-29 22:38 ` Jakub Narebski
2008-11-30 0:31 ` [PATCHv2 1/2] gitweb: fixes to gitweb feature check code Jakub Narebski
2008-11-29 10:48 ` [PATCHv2 0/2] " Jakub Narebski
2008-11-29 11:13 ` Giuseppe Bilotta
[not found] <Message-ID: <cb7bb73a0811291731g7f8770f7p89e924c00d2ab004@mail.gmail.com>
2008-11-30 1:34 ` [PATCH] gitweb: " Giuseppe Bilotta
2008-12-02 1:53 ` Jakub Narebski
2008-12-02 10:43 ` [PATCHv3bis] " Giuseppe Bilotta
2008-12-03 2:18 ` Junio C Hamano
2008-12-02 21:55 ` [PATCH] " Junio C Hamano
2008-12-03 1:21 ` Jakub Narebski
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=7vej0u1d2c.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=giuseppe.bilotta@gmail.com \
--cc=jnareb@gmail.com \
--cc=pasky@suse.cz \
/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).