[phobos] Ranges using runtime interfaces

[David Simcha]

In addition to the changes I made last night, I've also made the 
following changes:

1.  Change name to inputRangeObject/InputRangeObject.
2.  Add support for output ranges as outputRangeObject/OutputRangeObject.
3.  Remove the now ridiculous looking Hungarian notation on the interfaces.

http://pastebin.com/U83YNJfJ is where it's at.

Any more comments from anyone, or does this look ready to be checked in?

On 8/20/2010 12:01 AM, Andrei Alexandrescu wrote:
> 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
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>