Proposal for fixing import("file")

Tim M a at b.com
Sat Mar 14 09:38:16 PDT 2009


On Sun, 15 Mar 2009 02:22:05 +1300, Frank Benoit  
<keinfarbton at googlemail.com> wrote:

> 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.
>
> 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.
>
> I want to suggest to make the imported file relative to the module by
> default and if the path starts with a '/' search in the -Jpath.
> import("file") // search "file" in the directory of this module
> import("/file") // search "file" in -Jpath
> import("sub/file") // search in the sub package "sub" for the "file"
> For security reason, the ".." might be forbidden.
>
> 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.
>
>
>

Doesn't it work with templates and __FILE__ ?



More information about the Digitalmars-d mailing list