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

Zoltan Somogyi zoltan.somogyi at runbox.com
Sun Sep 20 16:41:33 AEST 2020


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 :-(

> (The diff looks fine.)

Thanks for that.

Zoltan.


More information about the reviews mailing list