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!)
