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
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
