On 27/05/2010 11:32, Steven Schveighoffer wrote:
> On Wed, 26 May 2010 10:06:32 -0400, Bruno Medeiros
> <brunodomedeiros+spam@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.


-- 
Bruno Medeiros - Software Engineer

On Fri, 28 May 2010 06:24:26 -0400, Bruno Medeiros <brunodomedeiros+spam@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@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

On Fri, 28 May 2010 06:10:49 -0400, Jacob Carlborg <doob@me.com> wrote:

> On 2010-05-27 12:32, Steven Schveighoffer wrote:
>> On Wed, 26 May 2010 10:06:32 -0400, Bruno Medeiros
>> <brunodomedeiros+spam@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.
>
> I've got my patch, for build Tango as a dynamic library on Mac, quite recently included in trunk. And I've also have a patch for druntime and Phobos in bugzilla just waiting to be included + one patch making it easier creating dynamic libraries directly with DMD. I would say it's a bad idea to still think that dynamic libraries aren't support, we have to think forward and assume they will be supported.
>

I remember that, and I'm very encouraged by it.  That being said, the ultimate goal is to have dmd be able to build dynamic libraries easily.  D has had dynamic library "support" for years, but you have to do all kinds of manual stuff, and the standard library isn't dynamic.  Until the standard library is dynamic, and I can build a dynamic library with a -shared equivalent switch, dynamic libs are a laboratory feature, and not many projects will use it.

Just so you know, I think it's important to support binary compatibility in dcollections, and since std.container has not adopted dcollections, I'm going to keep interfaces.  I was just pointing out the position others may have WRT binary support.

-Steve

On 2010-05-28 14:12, Steven Schveighoffer wrote:
> On Fri, 28 May 2010 06:10:49 -0400, Jacob Carlborg <doob@me.com> wrote:
>
>> On 2010-05-27 12:32, Steven Schveighoffer wrote:
>>> On Wed, 26 May 2010 10:06:32 -0400, Bruno Medeiros
>>> <brunodomedeiros+spam@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.
>>
>> I've got my patch, for build Tango as a dynamic library on Mac, quite
>> recently included in trunk. And I've also have a patch for druntime
>> and Phobos in bugzilla just waiting to be included + one patch making
>> it easier creating dynamic libraries directly with DMD. I would say
>> it's a bad idea to still think that dynamic libraries aren't support,
>> we have to think forward and assume they will be supported.
>>
>
> I remember that, and I'm very encouraged by it. That being said, the
> ultimate goal is to have dmd be able to build dynamic libraries easily.
> D has had dynamic library "support" for years, but you have to do all
> kinds of manual stuff, and the standard library isn't dynamic. Until the
> standard library is dynamic, and I can build a dynamic library with a
> -shared equivalent switch, dynamic libs are a laboratory feature, and
> not many projects will use it.

Yes, exactly, I noticed there isn't an easy way to build dynamic libraries, among other things you have to know the path to the standard library when manually building.

> Just so you know, I think it's important to support binary compatibility
> in dcollections, and since std.container has not adopted dcollections,
> I'm going to keep interfaces. I was just pointing out the position
> others may have WRT binary support.
>
> -Steve


-- 
/Jacob Carlborg