Skip to content

Kill off alphabetical ordering clause for publicly-exposed enum defs #851

@jengelh

Description

@jengelh

While working on #850 , I found this problematic statement in README/OPTIONS.md:

In `tidyenum.h` the `TidyOptionId` can be in any order, but please try to keep things alphabetical

When adding an option in the middle, all other option ids get pushed down (effectively incremented by one). This would break binary compatibility and expectations of existing programs, for example when such a program invokes:

tidyGetOption(td, TidyCSSPrefix /* 10 */);

If I were to add a a TidyAaaargh option and retaining alphabetical order, TidyCSSPrefix would become 11, and the program would receive, from tidyGetOption, the option for TidyCoerceEndTags (new 10).

I therefore seek reaffirmation that removing the "do it alphabetical" clause is the right thing to do, lest the SO version of the library must be bumped almost everytime such a new option is added.

The same holds true for any other enum that is publicly exposed, including, but not limited to, TidyStrings.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions