Hello Frank,
In Java there is the runtime possibility to access data files from the
same jar by getClass().getResourceAsStream(). This is used to
externalize data. With the D import("file"), we have this feature at
compiletime, which is fine.
But the problem in D is, "file" is search in a global scope
(-J<path>). So having such resource files used only locally by the
module is not possible. It must be taken care about name conflicts.
IIRC the -J things is to force the guy compiling to know there is an import
and where it's looking. I think that it should be left in. The global path
bit can be avoided by separate compilation. If you want to be able to have
different paths for different modules all from the same command line, tagging
the -J's per module or some sort f named root system might do well.
A second problem, I see is, that the generated .di files still have
the 'import("file")' statement in them. This means, that the user of a
.di still needs the resource file, taking care about more files in
this -Jpath.
nod
And i want to suggest to replace the import statement with the
imported file data (as a literal) for the generated .di file. This
makes using the .di more easy and ensures that the compiled object
file is using the same data as the .di file.
you might want to have a flag to swith that.
