Container hierarchy vs. container types

[Andrei Alexandrescu]

Steven Schveighoffer wrote:
> On Thu, 04 Mar 2010 18:22:55 -0500, Andrei Alexandrescu 
> <SeeWebsiteForEmail at erdani.org> wrote:
> 
>>
>> Needless to say, I'd be very curious to hear other opinions in this 
>> matter. Please speak up - the future of D depends, in small part, on 
>> this too.
> 
> As you know, you and I disagree on some aspects of containers.  However, 
> I think our philosophies are converging.
[snip]

To summarize my understanding of your points:

(a) When you only want to tweak a container's behavior in small ways, 
inheritance is great.

(b) Pass by reference is more natural for containers than pass by value.

(c) Proprietary code hiding is better with interfaces.

(d) Dynamically-linked code works best with interfaces.

(e) Interface-based code requires less recompilation and may save on 
generated code.

(f) Interfaces simplify understanding.

At the same time, you argue that ranges aren't fit as interfaces because:

(a) Inlinining is difficult/impossible

(b) Value semantics is more natural for ranges

(c) I didn't understand this because you changed the subject from ranges 
back to containers:

> I also think functions that can be tuned to each 
> implementation should be.  For this reason, dcollections containers 
> provide a lot of functionality that is not included in the interfaces, 
> simply because the functions are so specific to the implementation, it 
> would be the only class that implemented that interface.  For example, 
> all the functions that return cursors (and soon ranges) are not 
> interface functions.  This doesn't make them useless via interfaces, but 
> you cannot use every aspect of the container via an interface.  An 
> interface is like a common denominator, and I think it should be useful 
> for some purposes.  If nobody will ever use the interface as a parameter 
> to a function, then there is no point in declaring the interface (I 
> realize that I have created such interfaces in dcollections and I plan 
> to correct that -- one nice benefit of the contemplation triggered by 
> this discussion).

One other thing I'm worried about, and was an absolute pain in my 
preliminary tests of container implementations, is this issue of 
"iterators/ranges/cursors are not part of the container interface". It 
is absolutely fundamental that you can get an abstract range from an 
abstract container because most of what you can do to a container you 
must do with ranges. Otherwise the duplication of functionality is 
horrid. This failure alone is a reason to abandon the container 
hierarchy design.

> I am working on updating dcollections as we post, and I think I have 
> come up with a nifty way to do ranges that will both retain the 
> usefulness of the cursor, and provide a common way to plug the 
> collections into std.algorithm.
> 
> Good luck with your containers, I still hold out hope that dcollections 
> can be integrated in Phobos, but I probably need to get it working in 
> order to have any chance of competing :)

Good luck to you too. As I specified in my private message - if you undo 
the fundamental mistake of making find()/contains() part of the 
container (and of course all other disastrous mistakes of that kind), 
then I'm sure dcollections will be a very solid library.


Andrei