Re: The next step in a table driven client

> I'd much rather see a hash table than One Big Mother Structure that
> had the union of all possible flags and options. A hash table seems
> quite simple.

I vote for a big structure, because:

        * It will catch typos when you use options. Using a hash
          feels akin to using a prototyping language like perl
          (without "use strict"); it's quick and easy but it's also
          error-prone.

        * C structure lookups are more concise than APR hash lookups.
          Options will be used a lot, all over the client code, but
          only parsed in one contained section of code, so making
          option usage simpler is worth making option parsing a little
          more complex.

        * When you store an option, you need to check it against the
          list of valid option names for the particular command
          anyway. (This can be tabularized with either a structure or
          a hash. With a structure you have to use offsetof(); this
          is gross but not particularly more gross than using a
          non-type-safe hash or having to call the APR hash lookup
          function every time you use an option.)

Sure, you keep having to add entries to the structure. So what?
Received on Sat Oct 21 14:36:15 2006