D library projects

[Andrei Alexandrescu]

Steven Schveighoffer wrote:
> 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.

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