dcollections 1.0 and 2.0a beta released

[Steven Schveighoffer]

On Fri, 28 May 2010 06:24:26 -0400, Bruno Medeiros  
<brunodomedeiros+spam at com.gmail> wrote:

> On 27/05/2010 11:32, Steven Schveighoffer wrote:
>> On Wed, 26 May 2010 10:06:32 -0400, Bruno Medeiros
>> <brunodomedeiros+spam at com.gmail> wrote:
>>
>>> On 24/05/2010 16:45, Andrei Alexandrescu wrote:
>>>>> In the past I have built a C++ library that abstracted features of
>>>>> the OS. My goal was to make it possible to dynamically load a module
>>>>> that abstracted things like setting the IP address of a network
>>>>> interface. My modules used std::string instead of char * to lookup
>>>>> services to get objects that implement the interface. Big mistake. On
>>>>> a later version of the standard C++ runtime, the private
>>>>> implementation of std::string changed, so the dynamically loaded
>>>>> libraries crashed horribly. No change in string's interface, just the
>>>>> private stuff changed, but because it's a template, the code that
>>>>> uses it necessarily has to be aware of it. We ended up ditching the
>>>>> standard C++ library's version of string, and used STLPort so we
>>>>> could control the library.
>>>>>
>>>>> I envision this same sort of problem would be likely with D
>>>>> collection objects that were not used via interfaces.
>>>>
>>>> I see no problem retrofitting a no-interface container into a formal
>>>> interface if so needed.
>>>
>>>
>>> I don't understand this discussion: isn't the reason above pretty much
>>> a dead-on hard requirement for the collections to have interfaces?
>>> Something like, for example, an interface version of the range traits?
>>
>> Only if you wish to have binary compatibility with dynamic libs. Such a
>> thing isn't likely today since dynamic libs aren't very well supported
>> in D, and even phobos or dcollections isn't a dynamic lib.
>>
>
> Ah, nevermind, my mind slipped and I was thinking of any kind of  
> library, that is, static ones as well.
> Although even just dynamic library compatibility seems to be a valid  
> enough case that we should consider from the start, even if its not well  
> supported currently.

I agree, that's why dcollections has interfaces.

I'm keeping them there since std.container has gone its own direction.

-Steve