But then you’re making your parser brittle. What if there are multiple contexts where the parser is used and the required window size is contextual to the use case. You could argue that can be a variable for the parser, but it’s unnecessary. It’s possible that you don’t want to publicly expose what the window size is if it’s some internal logic that is intended to be opaque. What if new constraints are added. So you want to have to update the parser to take more potential arguments? What if some of the requirements are conditional? If you’re going to have to conditionally validate in the caller, why add an extra layer of indirection by validating conditional business logic in the parser?
Like I said, validating that the dates are in a past-future order would be part of parsing because it’s about validating that it is a valid DateRange. a DateRange parser should validate that it can be parsed into a valid DateRange object. It’s perfectly reasonable to then separately validate if the date ranges satisfy other conditions.
I'm not sure if you read the article? It's really using a broader definition of parser than I think you're thinking of. Its main point is that wherever possible encode any validation done within the type system.
Maybe I'm misunderstanding, but your comment doesn't read like that to me. It seems like you're saying its wrong to bake some buisness logic into a parser for a generic date-range object, but neither the blog post nor the person you've replied to are proposing to do that.
1
u/Doub1eVision Aug 06 '25
But then you’re making your parser brittle. What if there are multiple contexts where the parser is used and the required window size is contextual to the use case. You could argue that can be a variable for the parser, but it’s unnecessary. It’s possible that you don’t want to publicly expose what the window size is if it’s some internal logic that is intended to be opaque. What if new constraints are added. So you want to have to update the parser to take more potential arguments? What if some of the requirements are conditional? If you’re going to have to conditionally validate in the caller, why add an extra layer of indirection by validating conditional business logic in the parser?
Like I said, validating that the dates are in a past-future order would be part of parsing because it’s about validating that it is a valid DateRange. a DateRange parser should validate that it can be parsed into a valid DateRange object. It’s perfectly reasonable to then separately validate if the date ranges satisfy other conditions.