• Jonathan M Davis (11/11) Oct 10 2010 Okay, I'm trying to figure out how to take multiple .d files and use a s...
• Jesse Phillips (3/10) Oct 12 2010 I don't use .di files but it sounds like you what to use them for a diff...
• Jesse Phillips (6/19) Oct 12 2010 Reading it again it sounds like you are asking for one thing but describ...
• Jonathan M Davis (16/54) Oct 12 2010 Yes, I screwed up there. I should have put module x, not package x.
• Jonathan M Davis (7/25) Oct 12 2010 It's what Walter suggested doing to have a single std.datetime to import...
• Jesse Phillips (5/19) Oct 12 2010 And the later follow up.
• Jonathan M Davis (15/48) Oct 12 2010 would be confused on modules.

Jonathan M Davis <jmdavisProg gmx.com> writes:

Okay, I'm trying to figure out how to take multiple .d files and use a single
.di 
file for them. It looks like if you have x.di file with a corresponding x.d
file 
(so, only one .d file), you put package x; at the top of both files, and dmd is 
able to deal with it, knowing that the .d file holds the implementation for the 
.di file. But what about multiple .d files? I very much doubt that you can put 
package x; at the top of several .d files and have dmd be happy with you. You 
can't do that normally, but maybe you can do that if you have a .di file?

Or is the solution to have a single .d file which corresponds to the .di file
and 
havie it publicly import the other .d files?

Or is the solution something else entirely?

- Jonathan M Davis

Jesse Phillips <jessekphillips+D gmail.com> writes:

Jonathan M Davis Wrote:

 Okay, I'm trying to figure out how to take multiple .d files and use a single
.di 
 file for them. It looks like if you have x.di file with a corresponding x.d
file 
 (so, only one .d file), you put package x; at the top of both files, and dmd
is 
 able to deal with it, knowing that the .d file holds the implementation for
the 
 .di file. But what about multiple .d files? I very much doubt that you can put 
 package x; at the top of several .d files and have dmd be happy with you. You 
 can't do that normally, but maybe you can do that if you have a .di file?

I don't use .di files but it sounds like you what to use them for a different
purpose then what they are for. The .di is actually telling the linker where it
needs to find the functions. If you provide functions from multiple modules,
how will the linker know which module to look in to get the code?

Also if you have the .d file there is no need for the .di file (they aren't
header files). So what is the reason for only wanting one .di file?

Jesse Phillips <jessekphillips+D gmail.com> writes:

Jesse Phillips Wrote:

 Jonathan M Davis Wrote:
 
 Okay, I'm trying to figure out how to take multiple .d files and use a single
.di 
 file for them. It looks like if you have x.di file with a corresponding x.d
file 
 (so, only one .d file), you put package x; at the top of both files, and dmd
is 
 able to deal with it, knowing that the .d file holds the implementation for
the 
 .di file. But what about multiple .d files? I very much doubt that you can put 
 package x; at the top of several .d files and have dmd be happy with you. You 
 can't do that normally, but maybe you can do that if you have a .di file?

 
 I don't use .di files but it sounds like you what to use them for a different
purpose then what they are for. The .di is actually telling the linker where it
needs to find the functions. If you provide functions from multiple modules,
how will the linker know which module to look in to get the code?
 
 Also if you have the .d file there is no need for the .di file (they aren't
header files). So what is the reason for only wanting one .di file?

Reading it again it sounds like you are asking for one thing but describing
something different. And one thing is that you use 'module x' not 'package x' I
believe the latter will create a variable x which is only viewable with in the
package. And note that the module name defaults to the name of the file. A
package is a directory of modules (d files).

module packageName.moduleName;

import packageName.otherModule;

is a standard file opening. It says the module exists in packageName and named
moduleName, and I would like to use the functions found in the module
otherModule under packageName.

So if you wish to use functions specified by a .di file in multiple .d files
you must import the module, and provide a corresponding object file that
contains the code.

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Tuesday, October 12, 2010 16:20:50 Jesse Phillips wrote:
 Jesse Phillips Wrote:
 Jonathan M Davis Wrote:
 Okay, I'm trying to figure out how to take multiple .d files and use a
 single .di file for them. It looks like if you have x.di file with a
 corresponding x.d file (so, only one .d file), you put package x; at
 the top of both files, and dmd is able to deal with it, knowing that
 the .d file holds the implementation for the .di file. But what about
 multiple .d files? I very much doubt that you can put package x; at
 the top of several .d files and have dmd be happy with you. You can't
 do that normally, but maybe you can do that if you have a .di file?

 
 I don't use .di files but it sounds like you what to use them for a
 different purpose then what they are for. The .di is actually telling
 the linker where it needs to find the functions. If you provide
 functions from multiple modules, how will the linker know which module
 to look in to get the code?
 
 Also if you have the .d file there is no need for the .di file (they
 aren't header files). So what is the reason for only wanting one .di
 file?

 
 Reading it again it sounds like you are asking for one thing but describing
 something different. And one thing is that you use 'module x' not 'package
 x' I believe the latter will create a variable x which is only viewable
 with in the package. And note that the module name defaults to the name of
 the file. A package is a directory of modules (d files).
 
 module packageName.moduleName;
 
 import packageName.otherModule;
 
 is a standard file opening. It says the module exists in packageName and
 named moduleName, and I would like to use the functions found in the
 module otherModule under packageName.
 
 So if you wish to use functions specified by a .di file in multiple .d
 files you must import the module, and provide a corresponding object file
 that contains the code.

Yes, I screwed up there. I should have put module x, not package x.

But regardless, I'm not looking to use the functions specified in a .di file in 
multiple files. I'm looking to have the implementation of the functions
specified 
in the .di file to be in multiple files. So, the module that wants to use that 
functionality imports the .di file's module. I don't want to create a package.
I 
want a single module to import which has its implementation separated into 
several files.

So, the idea is to have a .di file with all of the declarations for the public 
API of the module, and then have the definitions for them (along with all of
the 
stuff private to the module) split into several files. The only way that I can 
think of doing so is to have a single .di file with a single corresponding .d
file 
which publicly imports the .d files with the implementation. What I'd like to 
know is whether that is the correct way to do that or whether there is another 
way.

- Jonathan M Davis

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Tuesday, October 12, 2010 16:07:29 Jesse Phillips wrote:
 Jonathan M Davis Wrote:
 Okay, I'm trying to figure out how to take multiple .d files and use a
 single .di file for them. It looks like if you have x.di file with a
 corresponding x.d file (so, only one .d file), you put package x; at the
 top of both files, and dmd is able to deal with it, knowing that the .d
 file holds the implementation for the .di file. But what about multiple
 .d files? I very much doubt that you can put package x; at the top of
 several .d files and have dmd be happy with you. You can't do that
 normally, but maybe you can do that if you have a .di file?

 
 I don't use .di files but it sounds like you what to use them for a
 different purpose then what they are for. The .di is actually telling the
 linker where it needs to find the functions. If you provide functions from
 multiple modules, how will the linker know which module to look in to get
 the code?
 
 Also if you have the .d file there is no need for the .di file (they aren't
 header files). So what is the reason for only wanting one .di file?

It's what Walter suggested doing to have a single std.datetime to import but 
have multiple modules for the actual implementation (he mentioned it in the 
datetime review thread on the Phobos list). He said to look at druntime for 
examples, but all of the .di files that I see there appear to have a single .d 
file corresponding to them. If there is one with multiple .d files, I missed it.

- Jonathan M Davis

Jesse Phillips <jessekphillips+D gmail.com> writes:

Jonathan M Davis Wrote:

 It's what Walter suggested doing to have a single std.datetime to import but 
 have multiple modules for the actual implementation (he mentioned it in the 
 datetime review thread on the Phobos list). He said to look at druntime for 
 examples, but all of the .di files that I see there appear to have a single .d 
 file corresponding to them. If there is one with multiple .d files, I missed
it.
 
 - Jonathan M Davis

Ah, yes. I thought you had done some big work in D, so I thought it odd you
would be confused on modules. I believe you were referring to this part from
Walter:

 Remember, if a module's implementation code is large, it can be split
 into a .di/implementation pair, rather than into multiple modules.

And the later follow up.

 Jonathan M Davis wrote:

    Really, the ideal would be to have all of it in one module but have the
code split up into several files. 
 The closest way that I was aware to do that was to use a single module which
publicly imported the 
 others. I'll look at splitting it into an interface file and source file
though.


 druntime does it for several modules, and can serve as an example.

I think I read into that differently. I was thinking he meant that by creating
a D interface file you no longer have all the implementation making the file
look big. I didn't understand the benefit, nor how it related to the problem.

On another note, why does druntime ship with .di files and .d files? Phobos is
only .d

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Tuesday, October 12, 2010 18:16:04 Jesse Phillips wrote:
 Jonathan M Davis Wrote:
 It's what Walter suggested doing to have a single std.datetime to import
 but have multiple modules for the actual implementation (he mentioned it
 in the datetime review thread on the Phobos list). He said to look at
 druntime for examples, but all of the .di files that I see there appear
 to have a single .d file corresponding to them. If there is one with
 multiple .d files, I missed it.
 
 - Jonathan M Davis

 
 Ah, yes. I thought you had done some big work in D, so I thought it odd you 

would be confused on modules.

Yeah. I understand modules well enough (though I'm not particularly familiar 
with .di files). I just screwed up in my post.

 I believe you were referring to this part from Walter:
 Remember, if a module's implementation code is large, it can be split
 into a .di/implementation pair, rather than into multiple modules.

 
 And the later follow up.
 
 Jonathan M Davis wrote:
    Really, the ideal would be to have all of it in one module but have
    the code split up into several files.
 
 The closest way that I was aware to do that was to use a single module
 which publicly imported the others. I'll look at splitting it into an
 interface file and source file though.

 
 druntime does it for several modules, and can serve as an example.

 
 I think I read into that differently. I was thinking he meant that by
 creating a D interface file you no longer have all the implementation
 making the file look big. I didn't understand the benefit, nor how it
 related to the problem.

Ah, and re-reading what he said, he wasn't suggesting that I have multiple .d 
files with a single .di file but rather that I have a single .di and single .d 
file. I misunderstood. That would explain why I couldn't find any code in
druntime 
which was splitting the implementation for a .di file into multiple files. The 
public imports in the .d file might still work as I suggested though. I'll look 
at using a single .d file though as see how big that is before I consider 
splitting them.

 On another note, why does druntime ship with .di files and .d files? Phobos
 is only .d

I think that this has come up and been answered before, but unfortunately, I 
don't recall what the reason was. I'd have to search through the archives to
find 
it. It does seem a bit odd though.

- Jonathan M Davis