Re: [RFC/PATCH] parse-options: introduce parse_subcommands
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jun 6, 2012, 17:26 UTC
- Message-ID
- <7vobowmjwr.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <CALkWK0nuJ2VrAUD5PsfnZzO5yDgB+h4xn8g=CTqmUvJ8DOdPNQ@mail.gmail.com>
Ramkumar Ramachandra <artagnon@gmail.com> writes:
Show 5 quoted lines
>> It looks like a static version of string_list_lookup() and does not >> have much reason to tie it to "subcommand". > > How so? I can use a string_list to keep subcommand->name and stuff > the callback into util. Where do I put subcommand->help then?
A string_list is a mapping from a string to an arbitrary piece of data; there is nothing that stops you from placing a pointer to a structure in its util field.
> I agree that there's no reason to tie it to subcommand though.
Yeah, if it were a generic API for a mapping from a string to an arbitrary piece of data that is determined at compile time, it would be a useful addition, and at that point, it is misleading to call that a "parse-subcommand" API. It is just a look-up mechansim in a fixed table keyed by strings.