Containers

bitwise via Digitalmars-d digitalmars-d at puremagic.com
Sat Sep 5 11:50:37 PDT 2015


On Saturday, 5 September 2015 at 06:59:28 UTC, Russel Winder 
wrote:
> On Fri, 2015-09-04 at 22:21 +0000, bitwise via Digitalmars-d 
> wrote:
>> This is another problem:
>>
>> --->FROM THE D DOCS
>>>    "Containers do not form a class hierarchy, instead they
>>> implement a common set of primitives (see table below). These
>>> primitives each guarantee a specific worst case complexity and
>>> thus allow generic code to be written independently of the
>>> container implementation."
>> 
>> I believe this is wrong, in that the point of abstraction 
>> should be the Ranges you get from the containers, not the 
>> containers themselves. I think it's a little silly for an 
>> Array(T) to have a "removeAny()" method.
>> 
>> 
>
> I think I am missing a step in the argument here:

Sorry.. I'm not sure if this is the source of confusion, but I 
was actually quoting the D documentation there. I've modified my 
message to make the quote more visible. That quote doesn't 
represent a point I agree with, but rather a point I'm trying to 
shoot down.

> if the point is that Ranges are the core of the abstraction, why
> does there need to be a class inheritance hierarchy.The lessons
> from C++, Java, Python, and Go, include that the obsession with 
> inheritance during the 1990s went far too far. Inheritance can 
> be useful, but for frameworks it is only conformance to 
> interfaces that matters for consistency across the framework. 
> Thus as long as every data structure type conforms to the 
> correct interface so that there is composability in the use of 
> Ranges, then things are fine.

I am saying that there should _not_ be a class hierarchy. 
Currently, there is no class hierarchy, but if you read that 
section I quoted from the container specification, it says that 
all containers should follow a pattern which allows algorithms to 
work on any container indiscriminately, which basically has the 
same effect as if all containers were forced to inherit the same 
interface. I believe this is over-generalization, and that the 
abstraction point should be backed-up to ranges. Trying to make a 
multi-map have the same interface as a vector or array, so that 
algorithms can be made to work on all containers 
indiscriminately, is a pipe dream. It's much more reasonable to 
expect algorithms to be able to work on any range, regardless of 
which container it has come from.

> This though is philosophy and far too general. To continue this 
> aspect of the debate we would need to deal in more specific 
> things. Are there some examples from Phobos and your containers 
> that we could pin this on?

With the containers I've built, I try to add overloads that take 
a ranges wherever possible(pushBack, push, insert, find, etc..).

The difference between my approach and the one suggested by the 
current container spec is that the spec would force me to name 
"pushBack" and "push" the same thing, even though the first one 
was a member function of a list/array/vector, and the second one 
was a member of a stack. Containers may turn out to have similar 
interfaces, but it's not a reason to rigidly define an interface 
to which all containers must adhere.

   Bit



More information about the Digitalmars-d mailing list