Another new io library

Steven Schveighoffer via Digitalmars-d digitalmars-d at puremagic.com
Thu Feb 18 10:27:28 PST 2016


On 2/18/16 12:16 PM, Wyatt wrote:
> On Thursday, 18 February 2016 at 16:36:37 UTC, Steven Schveighoffer wrote:
>> Note, asInputRange may not do what you want here. If multiple
>> zmqPollItems come in at once (I'm not sure how your socket works), the
>> input range's front will provide the entire window of data, and flush
>> it on popFront.
>>
> Not so great!  That's really not what I'd expect at all. :( (This isn't
> to say it doesn't make sense semantically, but I don't like how it feels.)

The philosophy that I settled on is to create an iopipe that extends one 
"item" at a time, even if more are available. Then, apply the range 
interface on that.

When I first started to write byLine, I made it a range. Then I thought, 
"what if you wanted to iterate by 2 lines at a time, or iterate by one 
line at a time, but see the last 2 for context?", well, then that would 
be another type, and I'd have to abstract out the functionality of line 
searching.

So I decided to just make an abstract "asInputRange" and just wrap the 
functionality of extending data one line at a time. The idea is to make 
building blocks as simple and useful as possible.

So what I think may be a good fit for your application (without knowing 
all the details) is to create an iopipe that delineates each message and 
extends exactly one message per call to extend. Then, you can wrap that 
in asInputRange, or create your own range which translates the actual 
binary data to a nicer object for each call to front.

So something like:

foreach(pollItem; zmqSocket.bufferedInput
     .byZmqPacket
     .asInputRange)

I'm still not 100% sure that this is the right way to do it...

Hm... if asInputRange took a template parameter of what type it should 
return, then asInputRange!zmqPacket could return zmqPacket(pipe.window) 
for front. That's kind of nice.

>> I'm thinking I'll change the name byInputRange to byWindow, and add a
>> byElement for an element-wise input range.
>>
> Oh, I see.  Naming.  Naming is hard.

Yes. It's especially hard when you haven't seen how others react to it :)

-Steve


More information about the Digitalmars-d mailing list