I looked through my code and remember now why I took a break. It was not just the printing stuff, it was that fact that the core:flags package inter-weaved much of the functionality, making it difficult to pick the parts you want for customizing and impossible to pick-n-choose procedures to control things. I felt that in order for customization to be possible, the parsing had to be completely separate and populate a known structure with the data, so a user would have the ability to get that data independent of the other procedures to use for customization.
This then had a fallout effect (realization of several things)
- If the parsing is separated out, then the validation procedures would have to be completely re-written to use the parsed structure.
- Support for custom validator would have to be re-written.
- Support for custom type setter would have to be re-written.
- Sorting would have to be re-written.
- Printing would have to be re-written.
- Decisions made on what is printed for various flag data. Type names, input options, etc.
- Since this would be a focus on customization, options for column width, colors, and other formatting options should be supported.
- A default procedure flow would need to be worked out for users who do not wish to customize or only customize a few things.
- Probably a few other details I’m leaving out.
Conclusion:
This meant that much (if not most of) the flags package would have to be re-written. While this is something that is possible, and I might still do someday (which is why I didn’t delete my existing effort), it seemed to make more sense that this was done in the core. So I posted about it in this thread.
Making a Case for Change:
The existing core:flags package appears to have been written with a focus on speed and efficiency, which is why I believe much of it is interwoven together. The result is less than ideal modularity. This make sense for many things in Odin, and a reason why most programs run so fast much of the time. For a package targeting usage (parsing, validation, printing, etc), the focus should be more on customization and modularity. Usage processing and printing is usually one of two things: 1. parse, print, exit - or - 2. parse, hold data for when ever user wants to print usage while program is active, exit. Performance and speed is negligible in those scenarios and virtually unnoticeable to a user, so customization should be the primary focus, not performance.