D Ranges

[Chris]

On Saturday, 14 September 2013 at 02:10:13 UTC, Jesse Phillips 
wrote:
>
> There isn't a guide in the manner you desire.
>
> In my experience I generally don't hold any more data than the 
> value returned by front (to prevent recalculation). Right now I 
> don't recall what situations I've needed to store the 
> intermediary data,

> but I know how you feel about having a input rang which is like 
> an output range simply returning a range to provide the 
> chaining ability.
>

Yes, this occurs sometimes. But I think it's due to my lack of 
experience with ranges, that's why I was asking, if there was a 
rough guide. I don't think I really need to store intermediate 
data in my components.

I'm not sure, however, if I should slowly migrate from OOP to 
structs. A of now I use them in two scenarios:

1. input / output ranges (flexible and interchangeable 
"workhorses")
2. storage of user defined data types, e.g. you could have a 
struct like this for an entry in a dictionary:

struct LexEntry {
   string lemma = "digital";
   string transcription = "Some IPA symbols";
   string[] definition = ["1. bla bla", "2. bla bla"];
}

At the moment, I use a lot of singletons in my program, because a 
lot of the data and data processing is handled by designated 
classes that do not to be reinstantiated. They just sit there 
waiting for input. In fact, without even noticing it, I designed 
parts of my program in an OO fashion that, in a way, makes OOP 
superfluous. So I'm beginning to wonder whether classes are 
really necessary. If I need features like sublcassing, I could 
just right another input range and add it to the chain. I'm still 
hesitant because a. if it's not broke, don't fix it and b. there 
might be some usage scenario when I'll need OO design and that I 
cannot yet foresee. But I agree that OO design is hard to 
unittest, it's not easy to single out a component and test it, 
because it's like a neurological network.