Exposing CsvReader structure to the public
Jesse Phillips via Digitalmars-d
digitalmars-d at puremagic.com
Thu Mar 19 13:14:17 PDT 2015
Over in this big long thread:
http://forum.dlang.org/post/otbosnagosqpvmskirtw@forum.dlang.org
There is mention of being able to store the csvReader struct:
On Tuesday, 17 March 2015 at 10:31:06 UTC, Almighty Bob wrote:
> It's far more useful for csvReader to return a type I know and
> can use than it is to obscure the return type for the sake of
> some philosophical ideal of increasing encapsulation.
So the question is, is this something people would really want?
Here is the signature for the struct return:
private struct CsvReader(Contents, Malformed ErrorLevel,
Range, Separator, Header);
This could be made public, and assuming you're not processing
text after a map!() or filter!() this struct would have
declarations like:
CsvReader!(string, Malformed.throwException, string, dchar,
string[]) foo;
vs today:
typeof(csvReader("")) foo;
Because it is private it also doesn't show up in the
documentation, maybe making it public would help to improve
documentation?
CsvReader also returns another internal range:
private struct CsvRecord(Contents, Malformed ErrorLevel,
Range, Separator);
This would be much harder to specify as a return type, because
CsvRecord is conditioned for three situations (struct/class,
hashtable, generic). I'm pretty sure to specify CsvReader.front's
return type I would need 3 different CsvReaders, which would mean
3 different csvReader helper functions, so we would see an API
change to:
CsvReaderStructured!(Contents, Malformed ErrorLevel, Range,
Separator, Header) csvReaderStructured!()()
CsvReaderHashTable!(Contents, Malformed ErrorLevel, Range,
Separator, Header) csvReaderHashTable()
CsvReaderDataOnly!(Contents, Malformed ErrorLevel, Range,
Separator, Header) csvReaderDataOnly!()()
This wouldn't need to be a breaking change as all the logic could
still be placed into the original 'auto csvReader()' function.
To Almighty's point, philosophical encapsulation has little to do
with the design, instead it was chosen to simplify the API.
More information about the Digitalmars-d
mailing list