On Sun, Mar 04, 2012 at 02:19:42PM +1100, Daniel Murphy wrote: > "H. S. Teoh" <hst...@quickfur.ath.cx> wrote in message [...] > > But perhaps a more pertinent question is, why is there so much > > duplication between aaA.d and object.AssociativeArray? For example, > > object.AssociativeArray basically copies (with modifications!) a > > bunch of implementation-dependent details from aaA.d, and sometimes > > uses that, and sometimes uses the other. Is it possible to dispense > > with this schizophrenic code duplication (which is very fragile, > > since changing the AA implementation in aaA.d will almost certainly > > break the Range stuff in AssociativeArray)? > > Ok, let me tell you a story. Once apon a time AAs were part of the > language proper, doing anything with them resulted in calls to > druntime c linkage functions, which you can see in aaA.d.
That makes sense. > Then, a few of years ago they were moved into druntime, so that the > implementation and interface could be improved without modifying the > compiler. Is that when struct AssociativeArray came into being? I'm still trying to understand how exactly AssociativeArray is connected with the C linkage implementation. Is the compiler "aware" of AssociativeArray at all? How does it work when you declare, say, int[string] and try to make a range out of it? > While only about three things were ever added to the AA interface, > this had the major side effect of introducing dozens of ice bugs and > _increasing_ the amount of code needed to support AAs, especially in > the interpreter and the glue layer. On top of this, most of the > functionality is still done with the compiler emitting druntime calls. And what are the issues preventing the compiler from *not* emitting these calls? > In the last release, Andrei made things worse by copying the AA > implementation layout into object.di in order to make ranges work. > (To be fair there isn't really a better way to do this with the > current setup.) I see. > We're basically stuck with this until someone comes up with a solution > that lets everything work as it should, with AAs completely in the > runtime or the compiler. [...] Heh. I just try to fix a few AA bugs and now I've to rewrite the thing from scratch? Let me think a bit more about that one. :) The question still stands, though, is there a reason for core.stdc.stdio to be compiled without the include path to druntime/src? T -- All men are mortal. Socrates is mortal. Therefore all men are Socrates.