Ranges

[Yigal Chripun]

Kristian Kilpi wrote:
> On Fri, 19 Jun 2009 03:13:11 +0300, Derek Parnell <derek at psych.ward> wrote:
>> Steve Teale (steve.teale at britseyeview.com) wrote:
>> Now I admit that these are not method names I would have choosen, as I
>> would have preferred names more like ... isEmpty(), getFront(),
>> moveForwards(), getBack(), moveBackwards(), getElement(N), addElement(E),
>> but the bikeshed gods have more wisdom than me ... and not that I'm
>> complaining of course.
> 
> I agree. Well, even if the names of the Range methods are a bit 'odd' 
> for me, I guess they are ok... except for empty().
> 
> If I have a container that I wan't to use as a Range, I can't use 
> empty() to empty the container (i.e. remove all the elements from it). :(
> 
> And yes, *I* am complaining here. ;)
> 
> I'm accustomed to use isXyz() for checking something and xyz() for doing 
> something (e.g. isEmpty() + empty()). What function name should I use 
> for emptying the container then? removeAllElements(), makeEmpty(), or 
> maybe even emptyThisContainer()...? :P
> 
> Hmm, should the Range methods use some special naming convention? E.g. 
> rangeFront(), rangePopFront()...?

while I agree with the general point about the naming convention, I 
don't see how is this a problem here since a range should be a distinct 
type from the container.
that means that you have for instance:
class Tree {
   void empty();
   ...
   TreeRange preOrder();
   TreeRange inOrder();
   TreeRange postOrder();
}

struct TreeRange {
   bool empty();
   ...
}

tree.empty(); // will empty the tree
auto range = tree.inOrder();
...
while (!range.empty()) { // will check if the range is empty
    // do stuff
}

this might be confusing but not impossible.