[phobos] Ranges using runtime interfaces

[Andrei Alexandrescu]

On 08/19/2010 10:42 PM, David Simcha wrote:
> I remember about a year and a half ago, there was talk of defining a
> wrapper module around ranges to make them more usable in cases where
> templates can't be used, such as virtual functions. I've revisited that
> now that I'm cleaning up ranges. I've created a fairly simple attempt at
> writing such a module. (http://pastebin.com/aDew6Kgg) This exercise has
> reinforced my conviction that about the only thing good about nominative
> typing is that it's easy to implement efficiently.

Well structural systems (which current ranges are) are also pretty easy 
to implement efficiently. Anyway, signs of OO clusterfrak are already 
visible in the explosion of iXxxAssignable interfaces.

Could you please add moveFront() and friends to the interfaces? Given 
that you've given up on ref returns (which I believe is a sound 
decision) we need some efficient means to destructively read stuff.

> I decided to exclude ref access to elements and infiniteness propagation
> from the interface entirely because I couldn't see a good way to
> implement these.
> I did, however, include assignable elements. Please
> review this module and tell me whether it looks worth including in
> Phobos and if so, where. Also, any suggestions on better naming would be
> greatly appreciated.

For starters, all types should start with a capital letter :o).

I think this is solid work that belongs to Phobos; thanks for doing it. 
The function runtimeRange will be the flagship of this module, and I 
hope we can find a very representative and memorable name for it. 
"runtimeRange" itself is no slouch, but I'm hoping for something even 
more descriptive. One problem is that the process of uniformizing 
templates under a common binary interface is not well known and not 
known under one definite name in all circles.

Here are some thoughts:

// weird typed range
auto r = chain(retro([1, 2]), SList!int(3, 4)[]);
// make it into a "nice" range
auto r1 = uniformize(r);
auto r1 = dynamic(r);
auto r1 = dynRange(r);
auto r1 = objectify(r);
auto r1 = rangeObject(r);
auto r1 = abiRange(r);

Of these, I guess I like rangeObject(r) the most. "Get me a range Object 
outta this range with some clusterfrak type."

Again, this is strong work. Congratulations, David.

About the code's place, I think it would simply belong inside std.range.


Andrei