• Frank Benoit (20/20) Mar 14 2009 In Java there is the runtime possibility to access data files from the
• Tim M (3/24) Mar 14 2009 Doesn't it work with templates and __FILE__ ?
• Frank Benoit (3/36) Mar 14 2009 Sorry, i don't understand that question.
• Tim M (3/40) Mar 14 2009 Nevermind. Slept now and I totally agree.
• BCS (8/25) Mar 14 2009 IIRC the -J things is to force the guy compiling to know there is an imp...

Frank Benoit <keinfarbton googlemail.com> writes:

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.

"Tim M" <a b.com> writes:

On Sun, 15 Mar 2009 02:22:05 +1300, Frank Benoit  
<keinfarbton 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__ ?

Frank Benoit <keinfarbton googlemail.com> writes:

Tim M schrieb:
 On Sun, 15 Mar 2009 02:22:05 +1300, Frank Benoit
 <keinfarbton 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?

"Tim M" <a b.com> writes:

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

 Tim M schrieb:
 On Sun, 15 Mar 2009 02:22:05 +1300, Frank Benoit
 <keinfarbton 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.

BCS <none anon.com> writes:

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.