D library projects

Steven Schveighoffer schveiguy at yahoo.com
Sun Nov 15 09:29:51 PST 2009


On Sun, 15 Nov 2009 11:49:18 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail at 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.

>
>> 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



More information about the Digitalmars-d mailing list