D Ranges

Chris wendlec at tcd.ie
Fri Sep 13 04:31:23 PDT 2013


A short report on component programming and ranges.

A lot of my code deals with transforming and reformatting input, 
e.g. text is split into sentences and words for grammatical 
parsing (part of speech) and phonetic transcriptions. I'm using D 
ranges and component programming and I'm quite happy with 
"one-liners" like

foreach 
(bySentence().byWord().byWhateverFormat().byReformatAgain()) {
    // Whatever
}

The code is much easier to maintain, neater and more efficient 
within each component.

Sometimes, however, I wonder how I should design my ranges. It is 
hard to decide whether to use them as pure pipes or semi-output 
ranges. "Semi" because they're not sinks as defined by put() but 
still they can hold data (an array of reformatted strings for 
example) that could be accessed by using Range.data. I'm not sure 
as regards "best practice" and whether or not I'm wasting 
resources by storing data internally. On the other hand, it might 
be handy to have access to the data stored internally. Does 
anyone have a rough guide to D ranges? Like Case 1: Use XYZ, Case 
2: Use ZYX etc.
(I've read this tutorial http://ddili.org/ders/d.en/ranges.html, 
and I'd like to thank Ali for that! It helped me a lot.)

Another issue I've come across is how to integrate CP and ranges 
into an OO framework. I figure that ranges are good work horses, 
but it makes sense to keep the overall logic in an OO fashion. Or 
could it be that D's structs and ranges will replace OOP as we no 
it (a class-free system).


More information about the Digitalmars-d mailing list