[armedbear-devel] Some thoughts on classloaders, ...

[Don Cohen]

Alessio Stalla writes:
 > The point is that classloaders already work like this! When
 > classloader X loads a class, and that class refers to class C, X is
 > asked by the JVM to load C as well. In abcl we are not using this
 > feature, rather we use an ad-hoc loading model that needs temporary
 > files. I propose to replace that completely and adopt the JVM way.
Ok, I think I finally understand all you said initially.
I'm sorry to have put you to so much trouble explaining it.
I hope a few others will benefit from this explanation.

 > ... However note that your example will probably be
 > compiled by abcl into a call like G.getSymbolFunction().execute(x)
Ok, that's a reasonable escape hatch.
 > i.e. G will not be resolved to a class at compile time (else how would
 > you handle redefinition?). However, what I'm talking about is (compile
 > 'f (lambda (x) (flet ((g (k) k)) (g x)))) - here g is known at compile
 > time, and compiled to its own class.
(I understood that.  The question above was a new one that arose in my
mind from what you had been describing.)

 > What I propose is this: suppose f is compiled to a class named foo41
 > and g to foo42, then in one of foo41's methods you'll have code like
 > LispObject g = new foo42(). When loading foo41 we'll use our
 > abcl-specific classloader which knows how to resolve foo42 too
 > (because it knows where to read it from memory or from the file
 > system, depending on the type of compilation), and everything
 > magically works (I hope :)
Sounds plausible but I can see why you say you hope.  Good luck.
And thanks for your patience.