Proposal for fixing import("file")

Frank Benoit keinfarbton at googlemail.com
Sat Mar 14 10:45:09 PDT 2009


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?



More information about the Digitalmars-d mailing list