[m-rev.] for review: ensure every option is initialized

[Julien Fischer]

On Sun, 20 Sep 2020, Zoltan Somogyi wrote:

>
> 2020-09-20 16:25 GMT+10:00 "Julien Fischer" <jfischer at opturion.com>:
>> Hi Zoltan,
>>
>> On Fri, 18 Sep 2020, Zoltan Somogyi wrote:
>>
>>> The diff itself is boring; I am seeking feedback on the concept.
>>>
>>> I am in two minds about this change. On the one hand, it does ensure that
>>> every option is initialized exactly once, which the old code did not,
>>> as evidenced by the fact that it caught an uninitialized option. On the other,
>>> it adds another several hundred lines to an already-too-large module,
>>> and the new version is not as readable as the old, due to the presence
>>> of the option category next to every option. We can ensure unique
>>> initialization only with a switch on the option at the top level, while
>>> I can't see a way to avoid listing the category next to each option
>>> without making the top level switch a switch on the category.
>>> The only resolution I can see is to make the option type
>>> not a single enum type like this:
>>>
>>> :- type option ---> opt1; opt2; ...
>>>
>>> but a structured type like this:
>>>
>>> :- type option ---> category1(opt_in_cat1) ; category2(opt_in_cat2) ...
>>>
>>> In this case, the top level switch on the category is also a switch
>>> on a (part of) the option itself. However, I am far from sure whether
>>> such a change is desirable.
>>
>> My preference is for the first approach.
>
> Would you mind disambiguating that? I don't know where you started
> counting :-(

I meant the approach that is used in this diff (i.e a single enum type).

Julien.