www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Exposing CsvReader structure to the public

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.
Mar 19 2015