All of lore.kernel.org
 help / color / mirror / Atom feed
From: ZheNing Hu <adlternative@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Christian Couder <christian.couder@gmail.com>,
	ZheNing Hu via GitGitGadget <gitgitgadget@gmail.com>,
	git <git@vger.kernel.org>, Jeff King <peff@peff.net>,
	Christian Couder <chriscool@tuxfamily.org>,
	Hariom Verma <hariom18599@gmail.com>
Subject: Re: [PATCH 2/2] [GSOC][RFC] ref-filter: introduce enum atom_type
Date: Sun, 9 May 2021 21:44:58 +0800	[thread overview]
Message-ID: <CAOLTT8Q3QLsD=yy8OBYcHh7FGhfmOebLVk71fidoih-X5HgNsQ@mail.gmail.com> (raw)
In-Reply-To: <xmqqh7jctiru.fsf@gitster.g>

Junio C Hamano <gitster@pobox.com> 于2021年5月9日周日 下午4:26写道:
>
> Christian Couder <christian.couder@gmail.com> writes:
>
> > I am not sure it's worth having an atom_type field for each valid_atom
> > element if the value of that field is already the index of the
> > element, because then one would always be able to replace
> > `valid_atom[i].atom_type` with just `i`. Or is it for some kind of
> > type safety issue?
>
> > I wonder if the enum should be instead defined like this:
> >
> > enum atom_type {
> > ATOM_UNKNOWN = 0,
> > ATOM_REFNAME,
> > ...
> > ATOM_ELSE,
> > ATOM_INVALID, /* should be last */
> > };
> >
> > As a struct containing an atom_type would typically be initialized
> > with 0 after being allocated, `ATOM_UNKNOWN = 0` could ensure that we
> > can easily distinguish such a struct where the atom_type is known from
> > such a struct where it is unknown yet.
> >
> > Having ATOM_INVALID as always the last enum value (even if some new
> > ones are added later) could help us iterate over the valid atoms using
> > something like:
> >
> > for (i = ATOM_UNKNOWN + 1; i < ATOM_INVALID; i++)
> >         /* do something with valid_atom[i] */;
>
> OK.
>
> As to "safety", I think it still makes sense to declare "enum", but
> I agree that we do not necessarily have to have it in the valid_atom[]
> struct.  We could do something like this instead:
>
>     static struct {
>             const char *name;
>             info_source source;
>             cmp_type cmp_type;
>             int (*parser)(const struct ref_format *format, struct used_atom *atom,
>                           const char *arg, struct strbuf *err);
>     } valid_atom[] = {
>            [ATOM_REFNAME] = { "refname", SOURCE_NONE, FIELD_STR, refname_atom_parser },
>            [ATOM_OBJECTTYPE] = { "objecttype", SOURCE_OTHER, FIELD_STR, objecttype...
>            [ATOM_OBJECTSIZE] = { "objectsize", SOURCE_OTHER, FIELD_ULONG, objectsi...
>            ...

Thank! Good suggection. We hope that the atom_type and
valid_atom items establish a clear connection. Maybe we
should add some comments before the definition of the
`enum atom_type` to remind the coder of the connection
between atom_type and valid_atom.

--
ZheNing Hu

  reply	other threads:[~2021-05-09 13:45 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-08 15:22 [PATCH 0/2] [GSOC][RFC] ref-filter: introduce enum atom_type ZheNing Hu via GitGitGadget
2021-05-08 15:22 ` [PATCH 1/2] [GSOC] ref-filter: add objectsize to used_atom ZheNing Hu via GitGitGadget
2021-05-08 15:22 ` [PATCH 2/2] [GSOC][RFC] ref-filter: introduce enum atom_type ZheNing Hu via GitGitGadget
2021-05-09  6:21   ` Christian Couder
2021-05-09  8:26     ` Junio C Hamano
2021-05-09 13:44       ` ZheNing Hu [this message]
2021-05-09 13:40     ` ZheNing Hu
2021-05-10 15:03 ` [PATCH v2 0/2] " ZheNing Hu via GitGitGadget
2021-05-10 15:03   ` [PATCH v2 1/2] [GSOC] ref-filter: add objectsize to used_atom ZheNing Hu via GitGitGadget
2021-05-10 15:03   ` [PATCH v2 2/2] [GSOC] ref-filter: introduce enum atom_type ZheNing Hu via GitGitGadget
2021-05-11  2:14     ` Junio C Hamano
2021-05-11  5:51       ` Christian Couder
2021-05-11  6:12         ` Junio C Hamano
2021-05-11 12:53           ` ZheNing Hu
2021-05-11 12:37         ` ZheNing Hu
2021-05-11 13:05         ` Junio C Hamano
2021-05-11 12:18       ` ZheNing Hu
2021-05-12 12:11   ` [PATCH v3 0/2] [GSOC][RFC] " ZheNing Hu via GitGitGadget
2021-05-12 12:11     ` [PATCH v3 1/2] [GSOC] ref-filter: add objectsize to used_atom ZheNing Hu via GitGitGadget
2021-05-12 23:11       ` Junio C Hamano
2021-05-13  9:04         ` ZheNing Hu
2021-05-12 12:11     ` [PATCH v3 2/2] [GSOC] ref-filter: introduce enum atom_type ZheNing Hu via GitGitGadget
2021-05-12 23:21       ` Junio C Hamano
2021-05-13  9:25         ` ZheNing Hu
2021-05-13 15:15     ` [PATCH v4 0/2] [GSOC][RFC] " ZheNing Hu via GitGitGadget
2021-05-13 15:15       ` [PATCH v4 1/2] [GSOC] ref-filter: add objectsize to used_atom ZheNing Hu via GitGitGadget
2021-05-13 15:15       ` [PATCH v4 2/2] [GSOC] ref-filter: introduce enum atom_type ZheNing Hu via GitGitGadget

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='CAOLTT8Q3QLsD=yy8OBYcHh7FGhfmOebLVk71fidoih-X5HgNsQ@mail.gmail.com' \
    --to=adlternative@gmail.com \
    --cc=chriscool@tuxfamily.org \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.com \
    --cc=hariom18599@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.