dcollections 1.0 and 2.0a beta released

[Walter Bright]

Michel Fortin wrote:
> On 2010-05-21 22:55:16 -0400, Walter Bright <newshound1 at digitalmars.com> 
> said:
> 
>> Walter Bright wrote:
>>> If we can get anywhere close to that level of success with ranges and 
>>> containers, we should all be well pleased.
>>
>> Mike Taylor has a phrase for that I think is well-coined: "impedance 
>> matching",
>> defined as the work necessary to get one library module to work with 
>> another
>> library module.
> 
> This makes me think about something.
> 
> In principle, I like the idea of containers being reference type. It 
> works well when passing a container to functions. But at the same time, 
> I despite it. By-reference containers forces you to have extra 
> indirections even when you don't need them, and you have to worry about 
> null. Sometime a value-type would be better, when creating more complex 
> data structures for instance:
> 
>     class Channel {
>         private {
>             Array!Message inbound;
>             Array!Message outbound;
>         }
> 
>         ...
>     }
> 
> What's the point of having extra indirection here?

Good question. I think the answer is:

1. When do you ever want to copy a collection? I almost never do, because 
copying one is an inherently expensive operation.

2. When you copy a collection, do you copy the container or the elements in the 
container or both? One would have to carefully read the documentation to see 
which it is. That increases substantially the "cognitive load" of using them.

3. Going to lengths to make them value types, but then disabling copying them 
because you want people to use them as reference types, seems like a failure of 
design somewhere.

4. That silly extra level of indirection actually isn't there. Consider that 
even value locals are accessed via indirection: offset[ESP]. For a reference 
collection we have: offset[EBX]. No difference (yes, EBX has to be loaded, but 
if it is done more than once it gets cached in a register by the compiler).

5. Just making them all reference types means the documentation and use become a 
lot simpler.