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
