Container hierarchy vs. container types

[Michel Fortin]

On 2010-03-05 01:53:32 -0500, Andrei Alexandrescu 
<SeeWebsiteForEmail at erdani.org> said:

> Robert Jacques wrote:
>> On Thu, 04 Mar 2010 18:22:55 -0500, Andrei Alexandrescu 
>> <SeeWebsiteForEmail at erdani.org> wrote:
>> [snip]
>> 
>> I like this idea. I've gotten used to using template constraints and 
>> ranges when coding which matches this strategy naturally. A lot of the 
>> capabilities seem to match ranges, but why did you use different names 
>> for some of them?
>> removeBack : popBack
>> removeFront: popFront
>> pushBack   : put
>> pushFront  : putFront?
> 
> It's intentional. You don't want to use a container as a range by mistake.

I agree that "put" has different semantics than "push" so the name 
should be different, but what's the difference in semantics between 
"remove" and "pop"? Both remove an element from the subject (range or 
container). I think they should share the same name.

You say you don't want to mix ranges with containers. But a container 
somewhat has the same semantics as an input stream: if you remove/pop 
something form it, it's no longer there for anyone. You decided to 
implement input streams as ranges, but at the same time you avoid 
reusing the same interface for containers; isn't that a little 
contradictory?

Why couldn't a container have the same interface as a range, only with 
the added ability to push elements into it?

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/