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

[H. S. Teoh]

On Sun, Mar 04, 2012 at 03:34:26PM +1100, Daniel Murphy wrote:
> "H. S. Teoh" <hsteoh at quickfur.ath.cx> wrote in message 
> news:mailman.372.1330833051.24984.digitalmars-d at puremagic.com...
[...]
> > 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?
> >
> 
> Yeah.  The compiler is aware of AssociativeArray in that it gags
> semantic errors on it, and turns V[K] types into
> AssociativeArray!(K,V) types in some cases (like for member lookup).
> It's sortof messy, try grepping for getImpl in dmd.

Hmph. Looks like there's no way to avoid massive overhaul? :-/


[...]
> >> 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?
> >
> 
> Well, for example:
> 
> aa[k] = v;
> becomes
> *__d_aaGet(&aa, k, k.typeinfo) = v; // or something like this
> 
> And iirc there is no way to currently do this through AssociativeArray.

But isn't this just a matter of overloading opIndex & friends? That's
what I'm trying to do, at any rate.


> >> 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. :)
> >
> 
> This is basically the conclusion I've come to when I've tried to fix
> AA bugs and run into these problems.  Patch the holes (and make things
> worse) or do a full redesign... neither have really inspired me to
> spend lots of time working on it.

Well, I'm not afraid of redesign per se -- I consider AA's an important
enough part of D to be worth the effort to do right. But I just wanted
to know what I'm up against. :P


> > The question still stands, though, is there a reason for
> > core.stdc.stdio to be compiled without the include path to
> > druntime/src?
> 
> I doubt it, though it's probably not desirable to make object.d import
> anything else.  Is there an extern c function you could call that
> would throw the range error for you?  If you make a pull request the
> people who maintain druntime will look though it. 
[...]

I suppose I *could* add a function in aaA.d to throw the exception.
Really ugly, but gets around needing an explicit dependency in
object.di.  I don't know which is worse though -- to make object.di
depend on core.exception, or to make aaA.d depend on it. Both are in
some ways circular dependencies.


T

-- 
Famous last words: I *think* this will work...