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
