D Ranges
Jesse Phillips
Jesse.K.Phillips+D at gmail.com
Fri Sep 13 19:10:09 PDT 2013
On Friday, 13 September 2013 at 11:31:24 UTC, Chris wrote:
> 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.)
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.
I also generally don't find a need to specify output ranges.
Output ranges are the end of the line so they kill component
programming
> 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).
I spent much of my initial time programming in Java, so I have a
good grasp of the constructs behind OOP (and a little bit of the
prototyping style known to be in Javascript). I also think I have
a pretty good grasp on designing for OOP, though I do have a lot
I could learn.
I hate OOP. I believe it has a place in software design, I just
haven't found it yet. Templates cause a lot of problem, though I
need to look into using the trick using /final/. Trying to do
inheritance when your interface defines that it takes a range or
returns a range. Though generics in C# work quite nicely.
The other issue I have is that OOP is very resistant to change
and testing. It is hard enough to get all the data needed for
your test cases, then throw in designing mock objects and blah
blah, it quickly becomes a mess. And even if you skip all the
testing aspects, if you want to make changes there is a giant
structure you're making changes for. Yes had I done a better job
designing my structure up front to allow for such change I
wouldn't be in this mess...
Anyway, my recommendation isn't to build up a class structure
just because that is what you would do in another language.
Figure out if the usability provided by inheritance is what you
want, if not struct with helper functions seems to be simplest in
development and maintenance. Destroy.
More information about the Digitalmars-d
mailing list