[phobos] Improvement of stream

[Andrei Alexandrescu]

(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
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos