D Ranges

[Chris]

On Monday, 16 September 2013 at 13:05:56 UTC, Chris wrote:
> 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.

that do not _have_ to be reinstantiated
  I could just right <= write (sorry, it's the Monday bug in my 
head!)