On Sun, 15 Nov 2009 11:49:18 -0500, Andrei Alexandrescu
<[email protected]> 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.
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...
-Steve
