Replacing AA's in druntime

[Dmitry Olshansky]

On 15.03.2012 2:44, Jakob Bornecrantz wrote:
> On Wednesday, 14 March 2012 at 09:07:40 UTC, Dmitry Olshansky wrote:
>> On 14.03.2012 6:39, Jakob Bornecrantz wrote:
>>> On Wednesday, 14 March 2012 at 00:52:32 UTC, H. S. Teoh wrote:
>>>> Hi all,
>>>>
>>>> My AA implementation is slowly inching closer to being ready to
>>>> replace aaA.d. So far I've been writing the implementation
>>>> outside of object_.d for ease of testing & development; now I'm
>>>> ready to start moving stuff into object_.d to start working on
>>>> integration with druntime.
>>>
>>> Hi,
>>>
>>> If I'm understanding this correctly you are moving the entire
>>> implementation of the AA into object.d and as such letting
>>> programs be purview to its inner working? In sort meaning you
>>> are making the entire AA implementation D ABI locked.
>>>
>>> This will make it impossible to either change the AA
>>> implementation in any ABI breaking fashion or make it impossible
>>> to pass AA's between libraries compiled against different
>>> versions of druntime.
>>
>> I will just point out that the major point of ABI is to make sure
>> different D compiler produce compatible object code. Thus it makes AA
>> implementation locked already anyway, right?
>
> Not true, as Steven said a opaque pImpl implementation would
> work, most modern C library design follow this principle with
> only using opaque except for pointers. This is because the ABI
> will then only require you call a certain set of functions (that
> can be extended to) not what that pointers points to, the
> details can be completely hidden.
>

Trouble is when one dynamic lib uses one version of druntime and AA, and 
your app another one. Guess what happens with this opaque pointer?


-- 
Dmitry Olshansky