Ad hoc ranges

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Fri Jan 21 18:20:03 PST 2011


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.

Andrei



More information about the Digitalmars-d mailing list