git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Han-Wen Nienhuys <hanwen@google.com>
Cc: git <git@vger.kernel.org>,
	Christian Couder <christian.couder@gmail.com>,
	Johannes Schindelin <johannes.schindelin@gmx.de>
Subject: Re: none
Date: Wed, 20 Nov 2019 13:52:56 +0900	[thread overview]
Message-ID: <xmqqsgmjb13r.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <CAFQ2z_OMr4J-gF1HXXkSQFheiDkf+7WBbn-oLYeDydmuLSfN1w@mail.gmail.com> (Han-Wen Nienhuys's message of "Tue, 19 Nov 2019 19:49:17 -0800")

Han-Wen Nienhuys <hanwen@google.com> writes:

> I spent the last few weeks cobbling together an implementation of the
> reftable format in C and in Go. I thought this would be cool to add to
> git-core, but I doubt whether I will have enough time to see such an
> effort through. Maybe some of you would want to try integrating it
> into the Git-core code base?  Example code is here:
>
>   https://github.com/google/reftable/blob/master/c/api.h#L153
>
> cheers!

My initial impression was that the API overuses typedef.  We tend to
avoid doing

	struct _foo { ... };
	typedef struct _foo foo;

and instead write "struct foo" explicitly to make us well aware of
what we are talking about.  That lets us see that we are passing or
returning a structure by value (which we would like authors to think
thrice before doing in C) like so quite easily:

	foo some_function(foo arg1, ...) { ... }

because it would be clear if it were written like so

	struct foo some_function(struct foo arg1, ...) { ... }

without hiding the structure behind a typedef (it also lets us avoid
names with leading underscore, which is frowned upon by some people
for different reasons).

But the set of operations defined in the header file seemed at the
right granularity in order to interface with the refs.h & refs/* API
we have.  It however was unclear to me how transactional ref updates
would work with it.

Thanks.

  reply	other threads:[~2019-11-20  4:53 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-20  3:49 Han-Wen Nienhuys
2019-11-20  4:52 ` Junio C Hamano [this message]
2019-11-20  5:00   ` none Han-Wen Nienhuys
2019-11-22 10:38   ` reftable (was: Re: none) Han-Wen Nienhuys
2019-11-20  5:30 ` your mail Taylor Blau
2019-11-20  8:05   ` Christian Couder
  -- strict thread matches above, loose matches on Subject: below --
2023-10-16 18:43 Dorcas Litunya
2023-10-17 20:21 ` none Junio C Hamano
2019-03-03 13:20 [PATCH 1/3] test functions: Add new function `test_file_not_empty` Junio C Hamano
2019-03-03 13:29 ` Rohit Ashiwal
2019-03-03 13:33   ` none Junio C Hamano
2018-10-05  6:20 [PATCH] doc: fix a typo and clarify a sentence Junio C Hamano
2018-10-10 15:20 ` Mihir Mehta
2018-10-10 22:19   ` none Junio C Hamano
2016-04-11 19:04 (unknown), miwilliams
2016-04-11 19:18 ` none Matthieu Moy

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=xmqqsgmjb13r.fsf@gitster-ct.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=hanwen@google.com \
    --cc=johannes.schindelin@gmx.de \
    /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).