Open kunyavskiy opened 7 months ago
Fair. We should either provide a better way to do it or at least make this code behave optimally (which is doable).
Some arguments against adding OPTIONAL_ZERO
:
alternativeParsing({
year(Padding.NONE); char('-'); monthNumber(Padding.NONE); char('-'); dayOfMonth(Padding.NONE)
}) {
year(); char('-'); monthNumber(); char('-'); dayOfMonth()
}
Padding.OPTIONAL_ZERO
is equivalent to Padding.ZERO
, and for people only using parsing, it's equivalent to Padding.NONE
. So, both classes of people get one more meaningless choice in the API. For formats that are used for both parsing and formatting, it may still help to clearly indicate the format that will be used for formatting, without having to sift through parsing-specific behavior, and alternativeParsing
does that.Let's collect more feedback and see how widespread the problem is. Everyone, please don't hesitate to share the ugly code that you're forced to write. Maybe we'll help you improve it, or maybe we'll see that OPTIONAL_ZERO
is an absolute necessity.
Will it parse something like 2024-3-07
? I'm not sure if Padding.NONE allows having padding.
But I agree, that reusing for both formatting and parsing is not a common case.
Will it parse something like 2024-3-07?
Yes.
I'm not sure if Padding.NONE allows having padding.
It does. We'll include this in the documentation, this information is missing.
Padding class now suggests only strict options. You either have NONE or ZERO or SPACE. Same for formating and parsing.
It looks like a common usecase to have a flexible parser but strict formatted.
This can be implemented now as
But this is quite verbose and probably suboptimal. I suggest to add Padding.OPTIONAL_ZERO and maybe something else similar. to fix it.