Is it bad for object.di to depend on core.exception?

Daniel Murphy yebblies at nospamgmail.com
Sat Mar 3 19:19:42 PST 2012


"H. S. Teoh" <hsteoh at quickfur.ath.cx> wrote in message 
news:mailman.370.1330829036.24984.digitalmars-d at puremagic.com...
> So I'm still working on fixing issue 5030, which *should* have been a
> trivial fix. But I'm running into a bunch of circumstantial problems,
> among which is this new method in AssociativeArray(Key,Value):
>
>    Value opIndex(Key key, string file=__FILE__, size_t line=__LINE__)
>    {
>    auto p = key in *cast(Value[Key]*)(&p);
> if (p) return *p;
> throw new RangeError(file, line);
>    }
>
> Originally it was simply Value opIndex(Key key) without any range check,
> which is probably a bad idea, so I added the throw RangeError in there.
>
> However, this introduces a dependency from object.di to core.exception.
> So this requires import core.exception in object.di, without which
> Phobos doesn't compile (for obvious reasons). But adding the import
> causes druntime to fail to compile, because, for example,
> core.stdc.stdio is compiled withouth druntime/src in the compiler's
> search path, so the compiler can't find core.exception.
>
> So I'm wondering, is it OK to add druntime/src to the compiler's search
> path when building druntime? Or is there a reason for the omission?
>
> 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.  Then, a few of years ago they were 
moved into druntime, so that the implementation and interface could be 
improved without modifying the compiler.  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.

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.)

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. 




More information about the Digitalmars-d mailing list