[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