Re: [boost] AlRangeExandrescu?

Subject: Re: [boost] AlRangeExandrescu?
From: Andrei Alexandrescu (andrei_at_[hidden])
Date: 2009-07-27 09:31:06

David Abrahams wrote:
> on Sat Jul 25 2009, Andrei Alexandrescu <andrei-AT-metalanguage.com> wrote:
> 
>> Thorsten Ottosen wrote:
>>> Andrei Alexandrescu skrev:
>>>> Mathias Gaunard wrote:
>>>>>> You would pass two adjacent ranges, like D's bringToFront (a generalization of
>>>>>> STL's rotate, see http://www.digitalmars.com/d/2.0/phobos/std_algorithm.html)
>>>>>> takes.
>>>>> Nice idea, that could work.
>>>>> But how can I generate those two adjacent ranges in the first place at reasonable
>>>>> costs? Do ranges requires to provide a constant time "complement" primitive?
>>>> There's no such need (a range could define it though).
>>>>
>>>> A design that has a bidirectional iterator walking freely up and down between two
>>>> limits would be difficult to port to ranges. (If the iterator is random-access,
>>>> things are trivial.) Ranges can only shrink, they never grow unless assigned from
>>>> the outside. So when you move one direction it would be difficult to grow one range
>>>> (shrinking the other is easy). That design would benefit from letting the iterator
>>>> abstraction exposed.
>>> Couldn't it be done with a special range that stores three iterators?
>> Yes, but not within the current primitive set. Sebastian's suggested interface
>> extension should work.
> 
> That isn't necessarily a good idea, though.  Complicating the Range
> abstraction undermines one of the best arguments in favor of the Range
> abstraction.

True, but I was expecting that. The thing is, I started with the 
absolutely minimal interface that could have ever worked (three 
functions: empty, front, popFront). I'd expected I'll need some more 
primitives, but I wanted to postpone defining them until the need 
arises. Turns out a great deal of useful stuff can be done with those 
three functions alone (plus the obvious addenda for bidirectional and 
random access).

I was still expecting that at some point more primitives would be needed 
(without being clear on what those primitives should look like), so I'm 
glad that this discussion is underway because it helps crystalizing 
those primitives. To me, finding that the range abstraction has 
shortcomings is therefore not a sign that we need to forgo it and get 
back to iterators, or that we need to have both iterators and ranges; 
it's simply an acknowledgment that the range design still needs completion.

Andrei