-
Notifications
You must be signed in to change notification settings - Fork 2
Description
The idea behind this "visitor"-based model is to enable intermediate subclasses that provide some of the services that "normal" text and CSV processing libraries offer, e.g., first-class headers with record field count validation, char instead of byte, that sort of thing, without sacrificing any meaningful degree of performance for cases that just need to treat a file as a stream of records that follow RFC 4180.
As with #18, I didn't anticipate that this would complicate API discovery, as these intermediate visitors (not just the one for #5, but also #7 and #8, and any others that come up) get in the way if they just live in the Cursively namespace.
At least the intermediate visitors should go into a sub-namespace. Probably the base one too, since the only time you should ever need to use that type is when creating a subclass, in which case there may be value to see all your options when typing "Cursively.BaseVisitors.".