Steven Schveighoffer wrote:
On Sun, 15 Nov 2009 11:49:18 -0500, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
Michel Fortin wrote:
I think shoehorning containers that are graph based into value
types might be a little strenuous. All the builtin D container
types are essentially reference types (arrays are not exactly
reference types but behave mostly like reference types), I don't
see why we should change that.
Making them classes allows for interfaces which helps allow runtime
decisions for things like copying data between containers that are
of different types. See dcollections and how easy it is to copy
data from one type to another.
I'm of the same opinion.
I couldn't find the details on copying. How does dcollections solve
it? It's a double dispatch issue.
I don't see how it's a double dispatch issue... If you want to copy
data from one container to another, you simply pass the container to add:
container1.add(container2);
Because they implement interfaces, there is only one function generated
for this (with templated structs, you'd need one implementation per
container combination). I do *some* optimization in case container2 is
the same type as container1. But for all containers, adding an element
is a quick operation and traversing to the next element is a quick
operation, so I don't see why you'd need special implementations for
certain combinations of containers, necessitating double-dispatch.
Ok, thanks for clarifying. I thought the overhead of traversal is
considerable, which would make it advantageous to specialize add on
select pairs of containers.
That said, I'm wondering if the container classes shouldn't also be
made final (unlike dcollections). Being classes would make them easy
to pass as interfaces, but them being
final would help skip the virtual calls whenever you don't pass them
as interfaces.
Sounds nice.
Yes, I intended to do that, but I wasn't sure if it made sense to
prevent people from inheriting from the classes, so I went the safer
route. My recent experiments have shown me that virtual calls actually
aren't all that more expensive anyways than just normal calls...
I see. Now, in this brave new world, inheritance seems to be often
shunned in favor of composition, and I see it plausible that a
library-offered container fosters composition if you want to provide
your own container.
Andrei
