Each step receives a context which provides the operation being performed, the location in the read file, and a per-reader/writer client provided object in addition to the raw data necessary to perform the step (object reference, string data, etc.).
The question is, are there any reasonable type or pattern that Cesil cannot support with this scheme?
"Reasonable" is a low bar here, if it's in actual in use code being read or written (even if manually) to a CSV I'd consider it a "reasonable" type no matter how otherwise weird.
This is an Open Question, which means:
[A]s part of the sustainable open source experiment I detailed in the first post of this series, any commentary from a Tier 2 GitHub Sponsor will be addressed in a future comment or post. Feedback from non-sponsors will receive equal consideration, but may not be directly addressed.
This was posed in Overthinking CSV With Cesil: “Maximum” Flexibility.
Cesil split reading and writing rows into a number of logical steps and let's clients provide their own implementations of those steps. They are:
Each step receives a context which provides the operation being performed, the location in the read file, and a per-reader/writer client provided object in addition to the raw data necessary to perform the step (object reference, string data, etc.).
The question is, are there any reasonable type or pattern that Cesil cannot support with this scheme?
"Reasonable" is a low bar here, if it's in actual in use code being read or written (even if manually) to a CSV I'd consider it a "reasonable" type no matter how otherwise weird.
This is an Open Question, which means: