I understand your point now this is about letting the guy specifying the line ending and this is really frequent.
>> I’d even propose to have it by default: a FileReference writeStream can >> return a ZnNewLineWriterStream wrapping the corresponding stream. >> By default it can be configured with the system’s default line ending >> convention (least surprise?). >> And then users can change it accordingly… >> >> Now I ask also myself what we could do when reading line endings from a file. >> I’m 98.761% convinced that in the image we should have a single line ending >> convention for strings, and that we should convert internal strings to the >> external representation of convenience explicitly. >> In this direction we could make that default read streams in FileSystem to >> automatically transform external line endings into internal line endings. > > Maybe, maybe. > > It would still create the assumption that the standard stream has lots of > functionality that you can automatically count on. Then it feels that we are > back to where we started. > > The goal was to simplify, with simple, compose-able functionality. > > I know that the implementation would still be more or less modular, but many > layers also carry a performance price. > > I feel like I am fighting a losing battle trying to simplify and clean up the > stream API. > > The fact that we cannot use Traits is another problem, because inheritance > does not cut it. See the old NILE project.
