Proposal for fixing import(file)
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 (-Jpath). 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.
Re: Proposal for fixing import(file)
On Sun, 15 Mar 2009 02:22:05 +1300, Frank Benoit keinfarb...@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 (-Jpath). 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__ ?
Re: Proposal for fixing import(file)
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 (-Jpath). 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.
Re: Proposal for fixing import(file)
Tim M schrieb: On Sun, 15 Mar 2009 02:22:05 +1300, Frank Benoit keinfarb...@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 (-Jpath). 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?
Re: Proposal for fixing import(file)
On Sun, 15 Mar 2009 06:45:09 +1300, Frank Benoit keinfarb...@googlemail.com wrote: Tim M schrieb: On Sun, 15 Mar 2009 02:22:05 +1300, Frank Benoit keinfarb...@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 (-Jpath). 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.
