Henrik,

> Does the attached cs fix the translator problems for you, wrt pool
> constants?

Yes, thanks a lot! [Note to Harvesters: Don't take the CS "as is". I've
already posted a version into the update stream which completes some of
the constant declarations].

> > Also, and this is the thing I don't understand, you've changed in
> > various places the references to globals residing in the 
> > same module by a Module @ #(Foo Bar Mumble) reference (for
> > instance refs to Interpreter in InterpreterSupportCode and refs
> > to FXBltSimulation in FXBltSimulator). Why is this necessary for
> > a module in order to be unloaded and loaded
> > again? Does this mean we have to qualify every reference to a global
> > explicitly?! If not, what are the rules when and where explicit
> > references are required?!
> 
> These had to be changed because they cause circular dependencies,
which
> prevent them from being loaded as independent modules if there are
> sub/superclass relationships between these modules. Removing 
> the references in this manner is only necessary in such cases.

Is there a way of detecting these dependencies early on?! E.g., are
circular references always problematic or only under certain
circumstances?!

> In the case of the FX classes, it might have been more 
> appropriate to move the simulator/plugin classes together
> with the other plugins.

Well, these should really be removed by now. They are simply unnecessary
since all the interesting stuff is handled in BitBlt itself.

> > The question
> > is basically, what do you do if you want to provide a 
> > (single) file in which should contain the appropriated definitions?!
> > Reviewing the information on the Swiki it says that you have
> > to convert pools into pool modules and describes how to do that
> > in ModuleRefactorer but what about people who need some _new_
> > shared constants?! ;-)
> 
> When you store a module the variables defined in it (but not 
> their contents) are stored with the other definitions. So your
> initializing code can assume the variables to exist and just
> initialize their values. No more Undeclared voodoo practices
> necessary.

Ah! That's nice. I wasn't aware that the modules pre-declare their names
in that way. That's really helpful.

Cheers,
  - Andreas