Proposal for fixing import("file")

[Tim M]

On Sun, 15 Mar 2009 06:45:09 +1300, Frank Benoit  
<keinfarbton at googlemail.com> wrote:

> Tim M schrieb:
>> 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__ ?
>
> Sorry, i don't understand that question.
> Can you explain?

Nevermind. Slept now and I totally agree.