Re: Module Clarification

2016-09-27 Thread Jonathan Marler via Digitalmars-d-learn
On Tuesday, 27 September 2016 at 13:48:39 UTC, Steven Schveighoffer wrote: On 9/22/16 4:16 PM, Jonathan Marler wrote: On Thursday, 22 September 2016 at 20:09:41 UTC, Steven Schveighoffer wrote: Before package.d support, you could not do any importing of packages. You could only import modules

Re: Module Clarification

2016-09-27 Thread Steven Schveighoffer via Digitalmars-d-learn
On 9/22/16 4:16 PM, Jonathan Marler wrote: On Thursday, 22 September 2016 at 20:09:41 UTC, Steven Schveighoffer wrote: Before package.d support, you could not do any importing of packages. You could only import modules. package.d was how the compiler allowed importing packages. I don't know th

Re: Module Clarification

2016-09-22 Thread Jonathan Marler via Digitalmars-d-learn
On Thursday, 22 September 2016 at 20:09:41 UTC, Steven Schveighoffer wrote: Before package.d support, you could not do any importing of packages. You could only import modules. package.d was how the compiler allowed importing packages. I don't know that there is a fundamental difference betw

Re: Module Clarification

2016-09-22 Thread Steven Schveighoffer via Digitalmars-d-learn
On 9/22/16 10:29 AM, Jonathan Marler wrote: If the package.d file didn't exist, then I don't think there would be any problem with hierarchical modules. Is this the right conclusion? Was package.d a mistake? Maybe the reasoning is that D doesn't really like hierarchical modules, so creating th

Re: Module Clarification

2016-09-22 Thread Jonathan Marler via Digitalmars-d-learn
On Thursday, 22 September 2016 at 15:02:01 UTC, Lodovico Giaretta wrote: I think that having package.d provides a better layout. Look at the difference between this: ls std/experimental drw-rw-rw- allocator drw-rw-rw- logger drw-rw-rw- ndslice -rw-rw-rw- typecons.d and this: ls std/exper

Re: Module Clarification

2016-09-22 Thread Lodovico Giaretta via Digitalmars-d-learn
On Thursday, 22 September 2016 at 14:29:20 UTC, Jonathan Marler wrote: Actually, the more I think about it, I'm not sure there's a good reason for the "package.d" semantics to exist. I guess it establishes a pattern when people would like to combine smaller modules into one public module, but

Re: Module Clarification

2016-09-22 Thread Jonathan Marler via Digitalmars-d-learn
On Thursday, 22 September 2016 at 11:40:17 UTC, Steven Schveighoffer wrote: This should be fine. x/package.d is equivalent to module x. Ok, it looks like no-one thought what I was doing was off-base. I guess this brings up another question. Why doesn't the compiler support modules in a hiera

Re: Module Clarification

2016-09-22 Thread Steven Schveighoffer via Digitalmars-d-learn
On 9/21/16 10:17 AM, Jonathan Marler wrote: I'm working on a code generation tool and wanted to make sure my module approach was correct. The generated code has a module hierarchy, where modules can appear at any level of the hierarchy. module foo; module foo.bar; In this case, module foo and

Re: Module Clarification

2016-09-21 Thread tcak via Digitalmars-d-learn
On Wednesday, 21 September 2016 at 14:17:56 UTC, Jonathan Marler wrote: I'm working on a code generation tool and wanted to make sure my module approach was correct. The generated code has a module hierarchy, where modules can appear at any level of the hierarchy. module foo; module foo.bar;

Module Clarification

2016-09-21 Thread Jonathan Marler via Digitalmars-d-learn
I'm working on a code generation tool and wanted to make sure my module approach was correct. The generated code has a module hierarchy, where modules can appear at any level of the hierarchy. module foo; module foo.bar; In this case, module foo and foo.bar are independent modules. The foo