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

H. S. Teoh hsteoh at quickfur.ath.cx
Sat Mar 3 18:45:37 PST 2012


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


T

-- 
People say I'm arrogant, but they're just ignorant fools.


More information about the Digitalmars-d mailing list