Re: Working with Modules
On Wednesday, 28 December 2016 at 02:12:32 UTC, pineapple wrote: On Wednesday, 28 December 2016 at 02:08:44 UTC, Guy Asking a Question wrote: import test; <---dmd choking here. You will need to use the -I option of dmd/rdmd to inform the compiler of where your `HopefullySomeDLibrary` directory is located, as well as any other places you will want to import modules from. If you're using another compiler, it should have a similar option. (Though I can't speak from experience.) Thanks. That did the trick.
Re: Working with Modules
On Wednesday, 28 December 2016 at 02:08:44 UTC, Guy Asking a Question wrote: import test; <---dmd choking here. You will need to use the -I option of dmd/rdmd to inform the compiler of where your `HopefullySomeDLibrary` directory is located, as well as any other places you will want to import modules from. If you're using another compiler, it should have a similar option. (Though I can't speak from experience.)
Re: Working with Modules
The code...
tester.d
module main;
import std.stdio;
import test; <---dmd choking here.
int main(string[] args)
{
writefln("Hello World\n");
writefln(add(a, b));
return 0;
}
test.d
module test;
int add(int a, int b)
{
return a + b;
}
Working with Modules
I am just starting up with dmd and code::blocks. Generally I have as my project structure something like this (sorry if your forum doesn't format this nicely, use the '-'es for directory nesting): ProjectA -SubProject1 -SubProject2 ProjectB -SubProject1 -SubProjectB HopefullySomeDProject -main.d Libraries -C --CLibrary1 -CPP --CPPLibrary1 -CSharp --CSharpLibrary1 -D --HopefullySomeDLibrary ---test.d Workspaces -csharp.sln -mydproject.workspace But it seems the D module system isn't playing nice with this setup. I keep getting this error: ||=== Build: Debug in tester (compiler: Digital Mars D Compiler) ===| tester.d|4|Error: module test is in file 'test.d' which cannot be read| ||=== Build failed: 1 error(s), 0 warning(s) (0 minute(s), 0 second(s)) ===| Unfortunately, neither code::blocks nor D's resources are really giving me any insight how I can make such a file structure work for me. Does D prefer more of a hierarchical structure where all libraries have to be in subdirectories? If so, how do people usually disembody the libraries from the actual projects?
Re: Working with modules
On 2013-02-16 05:14, Ali Çehreli wrote: mixin (import (part_of_my_module.d)); mixin (import (another_part_of_my_module.d)); How is that better than public imports. You'll get access to private declarations but besides that. -- /Jacob Carlborg
Re: Working with modules
On 02/16/2013 04:58 AM, Jacob Carlborg wrote: On 2013-02-16 05:14, Ali Çehreli wrote: mixin (import (part_of_my_module.d)); mixin (import (another_part_of_my_module.d)); How is that better than public imports. You'll get access to private declarations but besides that. I don't think it is better than any other solution. I got reminded of this possibility; that's all. :) Ali
Working with modules
Hi all, I have a question regarding how to lay out my code. I wish to have a project directory structure that resembles java projects (As I'm comfortable working in that sort of environment For example: $PROJHOME |-/src - Source code |-/lib - third party libraries |-/bin - Compiled binaries |-build.sh - script to build my project and stick the binary into 'bin' directory So, my src directory is where all my source code is going. Under source code, im going to have a few different folders. This is where my problem occurs. To illustrate: $PROJHOME |-/src |- utils |- Logger.d |- Properties.d |- SSHTool.d |- engine I want to put Logger.d, Properties.d and SSHTool.d into the module 'utils'. However, D's module system wont allow that, keeps throwing back errors to me saying 'utils' is conflicting (or something similar, cant remember the exact error). So, I've done a bit of reading, and found out that I should put all those classes into once source file, and put that file in the module 'utils'. Now, thats all fine and dandy, but I expect by the end of this experiment I will have quite a lot of utility classes and I really dont want them all in one source file. It becomes unwieldy imo. Does anyone here have any alternatives for me so that in my 'engine' or 'main' classes I can simply write: import utils; and still have my source files neatly laid out in manageable chunks? Thanks in advance...
Re: Working with modules
15-Feb-2013 13:51, Colin Grogan пишет: [snip] This is where my problem occurs. To illustrate: $PROJHOME |-/src |- utils |- Logger.d |- Properties.d |- SSHTool.d |- engine I want to put Logger.d, Properties.d and SSHTool.d into the module 'utils'. However, D's module system wont allow that, keeps throwing back errors to me saying 'utils' is conflicting (or something similar, cant remember the exact error). So, I've done a bit of reading, and found out that I should put all those classes into once source file, and put that file in the module 'utils'. Now, thats all fine and dandy, but I expect by the end of this experiment I will have quite a lot of utility classes and I really dont want them all in one source file. It becomes unwieldy imo. Does anyone here have any alternatives for me so that in my 'engine' or 'main' classes I can simply write: import utils; Another way is to create utils/_.d file that contains: public import utils.Logger; public import utils.Properties; public import utils.SSHTool; and import it like this: import utils._; The other popular name for this module is 'all'. and still have my source files neatly laid out in manageable chunks? Yeah, community at large wants a cleaner way to do this. It just wasn't sorted out yet: http://wiki.dlang.org/DIP14 http://wiki.dlang.org/DIP15 Thanks in advance... -- Dmitry Olshansky
Re: Working with modules
On Friday, February 15, 2013 10:51:00 Colin Grogan wrote: Does anyone here have any alternatives for me so that in my 'engine' or 'main' classes I can simply write: import utils; and still have my source files neatly laid out in manageable chunks? The only way that you can have a single import which imports multiple modules is if the module that you're importing publicly imports the other modules. And there is no way to do something like import utils.*; And remember that modules always correspond to files, and packages correspond to folders, so there's a one-to-one correspondance between what you'd import and what you'd put in the file system (unless you use public imports to make it so that importing a module imports stuff from outside that module). - Jonathan M Davis
Re: Working with modules
On Friday, 15 February 2013 at 10:01:35 UTC, Jonathan M Davis wrote: On Friday, February 15, 2013 10:51:00 Colin Grogan wrote: Does anyone here have any alternatives for me so that in my 'engine' or 'main' classes I can simply write: import utils; and still have my source files neatly laid out in manageable chunks? The only way that you can have a single import which imports multiple modules is if the module that you're importing publicly imports the other modules. And there is no way to do something like import utils.*; And remember that modules always correspond to files, and packages correspond to folders, so there's a one-to-one correspondance between what you'd import and what you'd put in the file system (unless you use public imports to make it so that importing a module imports stuff from outside that module). - Jonathan M Davis Ah, ok. So, I have my structure like so: $PROJHOME |-src |-utils |- Logger.d // contains module utils.Logger |- Props.d // contains module utils.Props |- utils.d // contains module utils; public import utils.Logger, utils.Props; Then, i just 'import utils' in my code. Or would I have to have Logger.d in a directory called src/utils/Logger/Logger.d to be able to declare the module 'utils.Logger'?
Re: Working with modules
On Friday, February 15, 2013 11:31:40 Colin Grogan wrote: So, I have my structure like so: $PROJHOME |-src | |-utils | |- Logger.d // contains module utils.Logger |- Props.d // contains module utils.Props |- utils.d // contains module utils; public import utils.Logger, utils.Props; Then, i just 'import utils' in my code. Or would I have to have Logger.d in a directory called src/utils/Logger/Logger.d to be able to declare the module 'utils.Logger'? utils/logger.d would be utils.logger. utils/logger/logger.d would be utils.logger.logger. The file paths and the import paths are identical. It's just that the file paths have slashes, and the import paths have dots. And unlike Java, there is zero connection between classes and modules. You could have many classes in a single module or none at all. Also, it's common practice to use all lowercase for module and package names (primarily to avoid any risk of different OSes treating the casing differently I believe - i.e. Windows doesn't care about casing whereas *nix does; so, on Windows, you could screw up you're casing, and it would work, whereas on Linux, it wouldn't). - Jonathan M Davis
Re: Working with modules
On Friday, 15 February 2013 at 10:31:41 UTC, Colin Grogan wrote: Ah, ok. So, I have my structure like so: $PROJHOME |-src |-utils |- Logger.d // contains module utils.Logger |- Props.d // contains module utils.Props |- utils.d // contains module utils; public import utils.Logger, utils.Props; Then, i just 'import utils' in my code. Or would I have to have Logger.d in a directory called src/utils/Logger/Logger.d to be able to declare the module 'utils.Logger'? Not exactly. With given layout you will need to use import utils.utils; in your code. There are no package imports in D currently at all. Separating modules into directories is not needed and will actually break everything. D module system maps to file system entities. File is a module. Directory is a package.
Re: Working with modules
On Friday, 15 February 2013 at 10:40:57 UTC, Dicebot wrote: On Friday, 15 February 2013 at 10:31:41 UTC, Colin Grogan wrote: Ah, ok. So, I have my structure like so: $PROJHOME |-src |-utils |- Logger.d // contains module utils.Logger |- Props.d // contains module utils.Props |- utils.d // contains module utils; public import utils.Logger, utils.Props; Then, i just 'import utils' in my code. Or would I have to have Logger.d in a directory called src/utils/Logger/Logger.d to be able to declare the module 'utils.Logger'? Not exactly. With given layout you will need to use import utils.utils; in your code. There are no package imports in D currently at all. Separating modules into directories is not needed and will actually break everything. D module system maps to file system entities. File is a module. Directory is a package. Ah ok, now I get it. Thanks for that everyone. Ill test it out once I get home. Cheers! I saw the wiki entry posted earlier with recommendations for different module/package management, is there any plans to implement any of these changes do you know?
Re: Working with modules
Ok, I had a minute so I tested it out.
I had the following:
src/main.d:
import utils._;
void main(string[] args){
logger l = new logger();
props p = new props();
l.print();
p.print();
}
src/utils/_.d
module utils._;
public import utils.props, utils.logger;
src/utils/logger.d
module utils.logger;
import std.stdio;
public class logger{
this(){}
public void print(){
writefln(This is logger...);
}
}
src/utils/props.d
module utils.props;
import std.stdio;
public class props{
this(){}
public void print(){
writefln(This is props...);
}
}
Compiled and ran it, and it printed out
This is logger...
This is props...
as I expected.
That's perfect, solves my problem quite well I think!
Thanks all!
Re: Working with modules
On 2013-02-15 12:04, Colin Grogan wrote: Ah ok, now I get it. Note that in Java you declare a package wheres in D you declare a module. If you have something like this in Java: // Baz.java package bar.foo; You would do this in D: // Baz.d module bar.foo.Baz; -- /Jacob Carlborg
Re: Working with modules
On Friday, 15 February 2013 at 10:01:35 UTC, Jonathan M Davis wrote: On Friday, February 15, 2013 10:51:00 Colin Grogan wrote: Does anyone here have any alternatives for me so that in my 'engine' or 'main' classes I can simply write: import utils; and still have my source files neatly laid out in manageable chunks? The only way that you can have a single import which imports multiple modules is if the module that you're importing publicly imports the other modules. And there is no way to do something like import utils.*; And remember that modules always correspond to files, and packages correspond to folders, so there's a one-to-one correspondance between what you'd import and what you'd put in the file system (unless you use public imports to make it so that importing a module imports stuff from outside that module). - Jonathan M Davis I was actually going to post a similar question, but it looks like this would be a better place to post! I know that a module can only be defined once, but I feel like there could be times where it would be helpful to be able to have the same module defined in separate files and I have an example. Right now, I am working on a binding and I am making use of the package access modifier to allow me to use internal objects that the end user will not be able to access directly. Problem is, my source files have many classes and are pretty convoluted. If I could define the module more than once I could split the source files up and it would be easier to work on, but I would still be able to share package declared objects and methods between modules like I do now. If I put the source files into their own packages, they are now hidden from source files I want them to be used in. Here's what I mean: mainpackage.system mainpackage.window mainpackage.graphics Anything defined with package is accessible between these. But... mainpackage.system.thing1 mainpackage.system.thing2 mainpackage.window.thing3 etc... Now things defined as package in mainpackage.system.thing1 are only accessible in mainpackage.system, but can't be accessed in mainpackage.window. Thoughts?
Re: Working with modules
On Saturday, 16 February 2013 at 03:50:12 UTC, Jeremy DeHaan wrote: I was actually going to post a similar question, but it looks like this would be a better place to post! I know that a module can only be defined once, but I feel like there could be times where it would be helpful to be able to have the same module defined in separate files and I have an example. Right now, I am working on a binding and I am making use of the package access modifier to allow me to use internal objects that the end user will not be able to access directly. Problem is, my source files have many classes and are pretty convoluted. If I could define the module more than once I could split the source files up and it would be easier to work on, but I would still be able to share package declared objects and methods between modules like I do now. If I put the source files into their own packages, they are now hidden from source files I want them to be used in. Here's what I mean: mainpackage.system mainpackage.window mainpackage.graphics Anything defined with package is accessible between these. But... mainpackage.system.thing1 mainpackage.system.thing2 mainpackage.window.thing3 etc... Now things defined as package in mainpackage.system.thing1 are only accessible in mainpackage.system, but can't be accessed in mainpackage.window. Thoughts? On Saturday, 16 February 2013 at 03:50:12 UTC, Jeremy DeHaan wrote: I was actually going to post a similar question, but it looks like this would be a better place to post! I know that a module can only be defined once, but I feel like there could be times where it would be helpful to be able to have the same module defined in separate files and I have an example. Right now, I am working on a binding and I am making use of the package access modifier to allow me to use internal objects that the end user will not be able to access directly. Problem is, my source files have many classes and are pretty convoluted. If I could define the module more than once I could split the source files up and it would be easier to work on, but I would still be able to share package declared objects and methods between modules like I do now. If I put the source files into their own packages, they are now hidden from source files I want them to be used in. Here's what I mean: mainpackage.system mainpackage.window mainpackage.graphics Anything defined with package is accessible between these. But... mainpackage.system.thing1 mainpackage.system.thing2 mainpackage.window.thing3 etc... Now things defined as package in mainpackage.system.thing1 are only accessible in mainpackage.system, but can't be accessed in mainpackage.window. Thoughts? I see this as more of a code architecture issue. It's up to you to decide which modules belong to which package, and that's that. If you see system and window as belonging to one package, then don't create subpackages. You can still split things up into separate modules if you need to: mainpackage.system mainpackage.systhing1 mainpackage.systhing2 mainpackage.window mainpackage.winthing3 You could keep your public-facing API in system and window or, if your design doesn't work that way, have things spread out over the various thing* modules and let system and window import them publicly. Either way, client code then imports system and window and pretends the rest don't exist. It would be nice to have a special module declaration to enforce this on the client side, something like: private module mainpackage.systhing1; Any module declared as such would not be importable outside of the package, but could still be explicitly imported into the namespace via a public import from another module in the same package.
Re: Working with modules
On Friday, February 15, 2013 20:14:41 Ali Çehreli wrote: On 02/15/2013 07:50 PM, Jeremy DeHaan wrote: I know that a module can only be defined once, but I feel like there could be times where it would be helpful to be able to have the same module defined in separate files There may be other ways of achieving that and I haven't given much thought to your question but there is also the import expression: http://dlang.org/expression.html#ImportExpression If needed, you can include D files similar to C's #include: mixin (import (part_of_my_module.d)); mixin (import (another_part_of_my_module.d)); You can play games like this if you really want to, but in general, it should be kept in mind that modules in D are designed to have a one-to-one correspondance with files, and packages are designed to have a one-to-one correspondance with directories. And in general, fighting that is just going to cause trouble and confusion. That doesn't necessarily mean that it should never be done, but in most cases, it would be far better to just reorganize your code so that it's not necessary. Also, AFAIK, mixing in imports is a very rare thing to do, so for the most part, people won't be expecting it, and it will likely cause maintenance issues for anyone else working on your project. What is more typically done when you need to split stuff up is to use internal modules which are only imported internally and are not presented as part of the public API, but even that isn't terribly common, I don't think (but unlike mixing in imports, it's something that the standard library actually does in a few places). - Jonathan M Davis
