On 04/25/2013 05:25 AM, Nathan Myers wrote:
On 04/24/2013 03:38 PM, Brian Anderson wrote:
## String encoding
I have not yet put much thought about how to deal with string
encoding and decoding. The existing `io` module simply has Reader and
Writer extension traits that add a number of methods like `read_str`,
etc. I think this is the wrong approach because it doesn't allow any
extra state for the encoding/decoding, e.g. there's no way to
customize the way newline is handled. Probably we'll need some
decorator types like `StringReader`, etc.
An opportunity not to be missed... since I/O objects are often
propagated through a system from top to bottom, they are an
excellent place to attach state that intermediate levels does not
need to know about. Such state traditionally includes locale-ish
formatting services, but the possibilities are much broader: time
zone, measurement-unit system, debug level, encryption/
authentication apparatus, undo/redo log, cumulative stats,
rate and resource limits -- the list goes on. Some of these
can be standardized, and many have been, but users need to
be able to add their own on an equal basis with standard
services.
## Close
Do we need to have `close` methods or do we depend solely on RAII for
closing streams?
close() can fail and report an error code. When you are not
interested in that, the destructor can do the job and throw
away the result, but often enough you need to know. Usually
there's not much to do about it beyond reporting the event,
but that report can be essential: did the data sent reach its
destination? If not, why not?
Thanks, that's an important consideration, so we do need 'close'.
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
