Le 18/09/2013 23:31, Brian Anderson a écrit :
On 09/10/2013 08:47 AM, Simon Sapin wrote:
Iterator<u8> and Iterator<char> are tempting, but we may need to work
on big chucks at a time for efficiency: Iterator<~[u8]> and
Iterator<~str>. Or could single-byte/char iterators be reliably
inlined to achieve similar efficiency?
Can Iterator<&[u8]> work if the iterator itself contains a fixed-sized
or preallocated buffer? For I/O purposes, allocating a bunch of buffers
just to write them out to a stream sounds wasteful..
[..]
I don't understand this iterator. I'm guessing it calls `concat` on the
`DecoderIterator` during each call to `next`, but `concat` consumes
`DecoderIterator`s inner `Iterator`, so it subsequent calls to `concat`
won't work.
Valid points, but please see the rest of this thread for the updated
proposal.
https://mail.mozilla.org/pipermail/rust-dev/2013-September/005556.html
I just removed the iterator stuff as it’s relatively easy to build on
top of the "push"-based API, and there are many variations of it, so we
don’t need to figure out the details in the first iteration.
This API only deals with Decoding. What about Encoding?
As noted in the proposals, it’s basically the same but with [u8] and str
swapped. I did not include it to keep the size of the email manageable.
I don't see the utility of the `Encoding` factory type here, especially
of instantiating it to get a `Decoder`. As you indicate, it's instance
methods may want to be static methods.
It’s not useful if you know the encoding to use at compile-time. (Eg.
this format always uses UTF-8.) It’s only useful for code that switches
encodings at run-time, based eg. on the charset parameter of a
Content-Type HTTP header. It’s used with a function that I forgot to
include in the first proposal:
fn get_encoding_from_label(label: &str) -> ~Encoding { /* ... */ }
Looks like a fine start to me. Let's do it.
I’m also looking for feedback on the error handling. Do you think
conditions are the right approach? How much power exactly should the
handlers have?
As to the implementation: rust-encoding has a lot that could be adapted.
https://github.com/lifthrasiir/rust-encoding
I may start doing the work at some point, but I’m not making any promise
on when. In the meantime, anyone interested feel free to take this up.
Cheers,
--
Simon Sapin
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
