Ad hoc ranges

[Tomek Sowiński]

Andrei Alexandrescu napisał:

> On 1/21/11 7:35 PM, Tomek Sowiński wrote:
> > Andrei Alexandrescu napisał:
> >
> >>> Like I said, anything that doesn't bother to expose range-interfaced iterators and is not performance critical is
> >>> considered a target for ad hoc ranges. Working with non-D libraries, or libraries ported to D but preserving
> >>> mother-language idioms. Tasks like traversing a tree of GUI widgets, or business specific objects where defining
> >>> proper ranges rarely happens and is use-case driven in practice. I expect they could be of some use in unittesting
> >>> as mock input. Vaguely related: educational -- ad hoc ranges read almost like a for loop so the learning curve for
> >>> ranges in general is eased off.
> >>>
> >>> Adding them to Phobos is an interesting idea. We need to evaluate their worth, though.
> >>>
> >>> Everybody: if you could write up a one-liner like range(empty, popFront, front), what would you use it for?
> >>
> >> How about a singleton range - a range with exactly one element. It could
> >> be done with repeat(x, 1) but let's try it with your function as a
> >> warm-up exercise.
> >
> > If x is nullable, range(x, x=null, x); it destroys x, though. Otherwise the state must be held separately on the
> > stack.
> >
> > bool empty;
> > auto r = range(empty, empty=true, x);
> >
> > So repeat(x, 1) wins this one. I think such nuggets can better be expressed as a degenerate case of existing
> > facilities. I envision ad hoc ranges at places where no iteration is defined and a one-off range struct doesn't
> > pay. Like database-backed entities which don't conform to any clear-cut data structure, but if you squint you see
> > it's sort of a tree, and you may just be able to e.g. walk through children recursively fetching only active ones
> > from DB, traverse columns of interest, and dump their content to a grid component which takes an arbitrary range of
> > values. And all this can be wrapped in std.parallelism to overlap DB round trips.
> 
> I think the challenge here is to figure out where to store the state. 
> The idiom makes it difficult for the delegates to communicate state to 
> one another.

On the stack, for loops do it for years.

-- 
Tomek