(I'm continuing to catch up with old messages. We need to get a
streaming interface done.)
1. I agree that the classic range interface offering byte[] from front()
is awkward to use when you want to read data in different fixed sizes. I
don't think that's a very frequent use case, but that doesn't really matter.
2. I agree that the extra copy could become an efficiency problem.
3. I think this:
size_t read(ubyte[] buf);
is a bit better than this:
ubyte[] read(ubyte[] buf);
because the latter favors people writing things like:
buf = stream.read(buf);
which is often undesirable (forces people to later allocate other
buffers of the appropriate size etc.)
Andrei
On 07/05/2010 11:37 AM, Ellery Newcomer wrote:
On 07/05/2010 10:49 AM, Andrei Alexandrescu wrote:
Good point. With ByChunk you only get to set the size once at
construction time. A natural extension of that would be to define a
property bufferSize that you can assign before calling popFront. That
would allow code like:
inp.bufferSize = 4;
inp.popFront();
process(inp.front);
inp.bufferSize = 100;
inp.popFront();
process(inp.front);
I reckon that just calling read() with different lengths is a bit more
appealing. Also if you need to save the data you need to call
inp.front.dup which makes for an extra copy. The question is how often
you need to do all that versus just getting whatever data is available.
Well, most of my D IO experience has been with binary files where you're
trying to get out fields of specific byte length and put them in
dedicated structures. Currently, I read the entire file (if phobos had a
standard InputStream interface thing I wouldn't be limited to files)
into an array and work with that. But that's kind of a horrid situation.
Note that std.zip is in the same boat.
The other thing is that extra copy. Personally, I'd rather the user
provide the buffer.
Also, I currently use an ad-hoc InputStream interface whose read
signature is
ubyte[] read(ubyte[] buffer);
which returns the slice of the buffer which was read in.
Do you have any opinion of this signature vs. the traditional signature?
For wrapping structs in general, I hope we could have a more general
version similar to BlackHole and WhiteHole - automatic wrapping.
Consider:
struct A {
this(int);
void foo();
int bar(string);
}
alias Classify!A ClassA;
ClassA is as if somebody sat down and wrote the following class by hand:
class ClassA {
private A payload;
this(int x) { payload = A(x); }
void foo() { return payload.foo(); }
int bar(string x) { return payload.bar(x); }
}
Things get more complicated with functions that receive or return type
A, properties, qualifiers etc. I think Classify would be an excellent
test of D's introspection capabilities, in addition to being useful in
practice.
That would be sweet
Andrei
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
