www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - is there a way to: import something = app-xyz-classes-something; ?

reply someone <someone somewhere.com> writes:
Since memory serves I use to name files with - instead of the 
more common _
Jun 20
parent reply frame <frame86 live.com> writes:
On Monday, 21 June 2021 at 03:32:58 UTC, someone wrote:
 Since memory serves I use to name files with - instead of the 
 more common _
The module name has to be strict and "-" is not allowed. However, you should be able to import files with a "-" in the name. From the manual:
 If the file name of a module is an invalid module name (e.g. 
 foo-bar.d), you may use a module declaration to set a valid 
 module name:
```d module foo_bar; ``` Tested on Windows/dmd - does NOT work :(
Jun 21
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 6/21/21 4:55 AM, frame wrote:
 On Monday, 21 June 2021 at 03:32:58 UTC, someone wrote:
 Since memory serves I use to name files with - instead of the more 
 common _
The module name has to be strict and "-" is not allowed. However, you should be able to import files with a "-" in the name. From the manual:
 If the file name of a module is an invalid module name (e.g. 
 foo-bar.d), you may use a module declaration to set a valid module name:
```d module foo_bar; ``` Tested on Windows/dmd - does NOT work :(
It does work. However, you have to tell the compiler the file to compile. When an import is used, the compiler does 2 stages: 1. Search through already-seen modules, and see if one matches 2. Search the filesystem to find a file that fits the module name. For example `std.path` becomes `$INCLUDE_DIR/std/path.d` So if you provide the file name to the compiler as part of the set of files to compile, it should work. e.g: foo-bar.d: ```d module foo_bar; ``` app.d: ```d module app; import foo_bar; void main () {} ``` compiled like: ```
 dmd app.d foo-bar.d
``` That being said, I strongly recommend just to name the file the same as the module name. -Steve
Jun 21
next sibling parent frame <frame86 live.com> writes:
On Monday, 21 June 2021 at 13:29:59 UTC, Steven Schveighoffer 
wrote:

 It does work. However, you have to tell the compiler the file 
 to compile.
Which completely ignores filenames if the compiler is satisified. You may assume by reading the manual that the compiler would make an automatic translation for illegal characters to "_" as module name to find a file in a directory - and that is not case. Supplying the filename manually makes this naming convention somehow irrelevant, if you get my point.
Jun 21
prev sibling next sibling parent someone <someone somewhere.com> writes:
On Monday, 21 June 2021 at 13:29:59 UTC, Steven Schveighoffer 
wrote:

 It does work. However, you have to tell the compiler the file 
 to compile.

 When an import is used, the compiler does 2 stages:

 1. Search through already-seen modules, and see if one matches
 2. Search the filesystem to find a file that fits the module 
 name. For example `std.path` becomes `$INCLUDE_DIR/std/path.d`

 So if you provide the file name to the compiler as part of the 
 set of files to compile, it should work. e.g:

 foo-bar.d:
 ```d
 module foo_bar;
 ```

 app.d:
 ```d
 module app;
 import foo_bar;

 void main () {}
 ```

 compiled like:

 ```
 dmd app.d foo-bar.d
``` That being said, I strongly recommend just to name the file the same as the module name. -Steve
Ironically I was already doing this on a shell script carrying all my source file names and switches for DMD, but since I started to, I did not retest changing back the names on the file system to a-b-c. I changed them right now and it works flawlessly. Issue solved. Thanks for the tip Steve :) !
Jun 21
prev sibling parent reply someone <someone somewhere.com> writes:
On Monday, 21 June 2021 at 13:29:59 UTC, Steven Schveighoffer 
wrote:

 That being said, I strongly recommend just to name the file the 
 same as the module name.
Although you made it clear that you do not favor this use-case I am really satisfied with your solution because, at least to me, has some pros; consider the following type "namespace" where sm stands for stock manager ie: the app prefix (and fw for framework ie: the common library): ```d import fw.code.common; /// framework; ie: app-independent common code import sm.code.common; /// app-specific common code import sm.types.common.currency; /// app-specific common types import sm.types.common.equity; import sm.types.specific.trade; /// app-specific specific types import sm.types.specific.position; import sm.types.specific.account; /// eg: + whatever /// eg: has accounts[] /// eg: has positions[] /// eg: has trades[] ``` ... linked as following with this build script: ```d /usr/bin/dmd \ "../common/code/fw-code-common.d" \ "./code/sm-code-common.d" \ "./types/sm-types-common-currency.d" \ "./types/sm-types-common-equity.d" \ "./types/sm-types-specific-trade.d" \ "./types/sm-types-specific-position.d" \ "./types/sm-types-specific-account.d" \ -w -de \ -run "./code/sm-code-app-demo.d" \ ; ``` ... and on each module: ```d module sm.code.app.demo; /// this matching the main demo app alias typeCurrencyFormat0 = sm.types.common.currency.gstrCurrencyFormat0; alias typeCurrencyFormat2 = sm.types.common.currency.gstrCurrencyFormat2; alias typeCurrencyFormat4 = sm.types.common.currency.gstrCurrencyFormat4; alias typeCurrencyRange = sm.types.common.currency.gudtCurrencyRange; alias typeStockID = sm.types.common.equity.typeStockID; alias typeTrade = sm.types.specific.trade.gudtTrade; alias typePosition = sm.types.specific.position.gudtPosition; alias typeAccount = sm.types.specific.account.gudtAccount; ``` Naming directory/files/type-namespace and aliasing this way allows me to: - move and rename source files as needed: only need to update the build script if so - aliasing the types I will be using in any given module once at the top of the source file and using this alias all the way back to the bottom: perfect hierarchical-unambiguously-namespace keeping code cleanliness all the way down; no-need to rename anything on any source file when its name/placement changes on the file-system. - although I am currently mimicing the type namespace following the file-system file/directory structure I am able to build the namespace independent of the file-system if I wanted to; say, the name-space using all lower-case letters while the file-system using mixed caps and spaces instead of _ or - or non-latin glyphs or whatever. What I like most of it is that it scales well for big and complex apps while being really flexible ... and neat :)
Jun 25
parent reply frame <frame86 live.com> writes:
On Saturday, 26 June 2021 at 02:19:18 UTC, someone wrote:

 What I like most of it is that it scales well for big and 
 complex apps while being really flexible ... and neat :)
If you pass each file to the compiler like in your script then every naming convention becomes irrelevant because the compiler does not need to do a file system lookup anyway and a module "foo_bar" could be also in the file xyz.d. But however, to have files organized is always a good idea.
Jun 25
parent someone <someone somewhere.com> writes:
On Saturday, 26 June 2021 at 04:24:05 UTC, frame wrote:

 If you pass each file to the compiler like in your script then 
 every naming convention becomes irrelevant because the compiler 
 does not need to do a file system lookup anyway and a module 
 "foo_bar" could be also in the file xyz.d.
You put it in far better words than mine -this paragraph should be in the docs :)
Jun 26