Inline Module / Namespace
D kinda lacks a way of creating a module/namespace inside another
file.
D does have modules but they have to be in separate files.
(Though separate files may be better coding practice, why is it
D's job to tell me how to code.)
I think a simple way to do this with existing syntax is to add
functionality for `module` to be used as a block.
module modulename {
void fun(){}
}
modulename.fun();
An inline module.
Re: Inline Module / Namespace
On 9 March 2018 at 10:44, Jonathan via Digitalmars-d
wrote:
> D kinda lacks a way of creating a module/namespace inside another file.
>
> D does have modules but they have to be in separate files. (Though separate
> files may be better coding practice, why is it D's job to tell me how to
> code.)
>
> I think a simple way to do this with existing syntax is to add functionality
> for `module` to be used as a block.
>
>
> module modulename {
> void fun(){}
> }
> modulename.fun();
>
>
> An inline module.
If you tried to `import modulename;` from some other module... how
would the compiler know where to find it?
Re: Inline Module / Namespace
I'm sure he meant:
```
--- foo.d
module foo;
module foo.bar{
void fun(){}
}
--- foo2.d
import foo.bar;
```
On Fri, Mar 9, 2018 at 10:51 AM, Manu via Digitalmars-d
wrote:
> On 9 March 2018 at 10:44, Jonathan via Digitalmars-d
> wrote:
>> D kinda lacks a way of creating a module/namespace inside another file.
>>
>> D does have modules but they have to be in separate files. (Though separate
>> files may be better coding practice, why is it D's job to tell me how to
>> code.)
>>
>> I think a simple way to do this with existing syntax is to add functionality
>> for `module` to be used as a block.
>>
>>
>> module modulename {
>> void fun(){}
>> }
>> modulename.fun();
>>
>>
>> An inline module.
>
> If you tried to `import modulename;` from some other module... how
> would the compiler know where to find it?
Re: Inline Module / Namespace
On Friday, 9 March 2018 at 18:51:50 UTC, Manu wrote: If you tried to `import modulename;` from some other module... how would the compiler know where to find it? The compiler has to parse the module to find them correctly already. When you do foo.bar into foo/bar.d, it is just the first guess the tools take by convention. If you pass the module on the command line the compiler actually parses them to find the name anyway and the file system location/name is irrelevant.
Re: Inline Module / Namespace
On Friday, March 09, 2018 18:44:07 Jonathan via Digitalmars-d wrote:
> D kinda lacks a way of creating a module/namespace inside another
> file.
>
> D does have modules but they have to be in separate files.
> (Though separate files may be better coding practice, why is it
> D's job to tell me how to code.)
It may not be the language's job to tell you how to code, but inevitably,
decisions haave to be made in the language design which essentially express
an opinion about how things should work, and the result is going to either
be the way you want it, or it isn't. In this case, it simplifies things
considerably to have modules correspond to files and packages correspond to
directories, and plenty of folks would argue that it's bad practice to do
otherwise (though obviously, there's some disagreement on that). Regardless,
it's the way that D went, and based on what Walter has said on it in the
past, I'd be very surprised to ever see that change. As with any language,
there are things that you're either going to have to put up with or decide
that they annoy you enough that you'd rather use another language.
> I think a simple way to do this with existing syntax is to add
> functionality for `module` to be used as a block.
>
>
> module modulename {
> void fun(){}
> }
> modulename.fun();
>
>
> An inline module.
You can always do something like declare a final abstract class with static
functions to create a new namespace of sorts in that any symbols inside it
then must be referred to using the class name, but it's not actually a
module and won't be directly importable as such, and without aliases, the
"namespace" must always be used when referring to the functions. It's not
something that's generally considered to be particularly good practice
though. Phobos does it in a couple of places where it seemed to make sense
at the time, but it's not something that's caught on, and I doubt that
anything more will ever be added to Phobos which does it. Regardless, I
expect that that's the closest that you'll ever get to declaring a module
within a module in D.
- Jonathan M Davis
