All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Karsten Blees <karsten.blees@gmail.com>
Cc: Heiko Voigt <hvoigt@hvoigt.net>,
	git@vger.kernel.org, Jens Lehmann <jens.lehmann@web.de>,
	Jonathan Nieder <jrnieder@gmail.com>, Jeff King <peff@peff.net>
Subject: Re: [PATCH 1/5] hashmap: add enum for hashmap free_entries option
Date: Thu, 12 Jun 2014 12:12:58 -0700	[thread overview]
Message-ID: <xmqqegyu54cl.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <53981D6A.3090604@gmail.com> (Karsten Blees's message of "Wed, 11 Jun 2014 11:12:10 +0200")

Karsten Blees <karsten.blees@gmail.com> writes:

> Am 10.06.2014 12:17, schrieb Heiko Voigt:
>> The intention of Jonathans critique here[1] was that you do not see what
>> this parameter does on the callsite. I.e.:
>> 
>> 	hashmap_free(&map, 1);
>> 
>> compared to
>> 
>> 	hashmap_free(&map, HASHMAP_FREE_ENTRIES);
>> 
>> A boolean basically transfers the same information and would not help
>> the reader here.
>> 
>> Cheers Heiko
>> 
>> [1] http://article.gmane.org/gmane.comp.version-control.git/243917
>> 
>
> There are languages where you can have e.g. 'hashmap_free(...,
> free_entries: true)'. In C, however, you do not see what a
> parameter does at the call site. This is a general language
> feature, reducing redundancy and keeping it short and concise. IMO
> there's no reason to treat boolean parameters differently.

But given that you are writing in C, is any of that relevant?  We do
want to keep our call-sites readable and understandable, and 1 or
true would not help, unless (1) you are the one who wrote the
function and know that 1 means free the entries, or (2) the API is
so widely used and everybody knows what 1 means free the entries.

  reply	other threads:[~2014-06-12 19:13 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-05  6:04 [PATCH 0/5] submodule config lookup API Heiko Voigt
2014-06-05  6:06 ` [PATCH 1/5] hashmap: add enum for hashmap free_entries option Heiko Voigt
2014-06-06 17:52   ` Karsten Blees
2014-06-10 10:17     ` Heiko Voigt
2014-06-11  9:12       ` Karsten Blees
2014-06-12 19:12         ` Junio C Hamano [this message]
2014-06-17  8:30           ` Karsten Blees
2014-06-17 19:04             ` Heiko Voigt
2014-06-17 22:19               ` Junio C Hamano
2014-06-05  6:07 ` [PATCH 2/5] implement submodule config cache for lookup of submodule names Heiko Voigt
2014-06-05 17:46   ` W. Trevor King
2014-06-06  5:20     ` Heiko Voigt
2014-06-08  9:04   ` Eric Sunshine
2014-06-10 10:19     ` Heiko Voigt
2014-06-12 21:58   ` Junio C Hamano
2014-06-13 22:37     ` Heiko Voigt
2014-06-05  6:08 ` [PATCH 3/5] extract functions for submodule config set and lookup Heiko Voigt
2014-06-05  6:09 ` [PATCH 4/5] use new config API for worktree configurations of submodules Heiko Voigt
2014-06-05  6:09 ` [PATCH 5/5] do not die on error of parsing fetchrecursesubmodules option Heiko Voigt
2014-06-12 21:59 ` [PATCH 0/5] submodule config lookup API Junio C Hamano
2014-06-13 22:41   ` Heiko Voigt
2014-06-16 17:58     ` Junio C Hamano
2014-06-17 19:00       ` Heiko Voigt
2014-06-12 22:04 ` Junio C Hamano
2014-06-13  7:13   ` Jens Lehmann
2014-06-13 17:50     ` 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=xmqqegyu54cl.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=hvoigt@hvoigt.net \
    --cc=jens.lehmann@web.de \
    --cc=jrnieder@gmail.com \
    --cc=karsten.blees@gmail.com \
    --cc=peff@peff.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.