Re: Best practice and module declarations
On 15.07.2010 23:28, Rory McGuire wrote: On Thu, 15 Jul 2010 23:08:07 +0200, torhu wrote: On 15.07.2010 21:59, Rory McGuire wrote: From what I remember in TDPL: Can be used to rename a module if you have it in a different directory structure than how you use it. E.g. implementation and "headers" in separate folders. If you use *.di files (headers), you would normally just keep the directory structure, but put the whole thing in a different root directory. Just having *.d and *.di files in the same directory works too, as the compiler prefers the *.di files. Andrei's use case was if you had multiple teams of programmers with some allowed to work on interfaces and others only allowed to work on the implementations. Can be used to rename module when a filename is not a valid D symbol. That would fool the D-specific build tools, and DMD itself too. In most cases it's easier to just rename the file too. It can be made to work using a *.di file if you really have to. Andrei's example had hyphens in the file name, sometimes policy comes first? yes no. Not that I can think of a reason for the policy off hand perhaps GTK naming convention. Seem a bit far fetched those examples, but ok ;)
Re: Best practice and module declarations
On Thu, 15 Jul 2010 23:08:07 +0200, torhu wrote: On 15.07.2010 21:59, Rory McGuire wrote: From what I remember in TDPL: Can be used to rename a module if you have it in a different directory structure than how you use it. E.g. implementation and "headers" in separate folders. If you use *.di files (headers), you would normally just keep the directory structure, but put the whole thing in a different root directory. Just having *.d and *.di files in the same directory works too, as the compiler prefers the *.di files. Andrei's use case was if you had multiple teams of programmers with some allowed to work on interfaces and others only allowed to work on the implementations. Can be used to rename module when a filename is not a valid D symbol. That would fool the D-specific build tools, and DMD itself too. In most cases it's easier to just rename the file too. It can be made to work using a *.di file if you really have to. Andrei's example had hyphens in the file name, sometimes policy comes first? yes no. Not that I can think of a reason for the policy off hand perhaps GTK naming convention.
Re: Best practice and module declarations
On 15.07.2010 21:59, Rory McGuire wrote: From what I remember in TDPL: Can be used to rename a module if you have it in a different directory structure than how you use it. E.g. implementation and "headers" in separate folders. If you use *.di files (headers), you would normally just keep the directory structure, but put the whole thing in a different root directory. Just having *.d and *.di files in the same directory works too, as the compiler prefers the *.di files. Can be used to rename module when a filename is not a valid D symbol. That would fool the D-specific build tools, and DMD itself too. In most cases it's easier to just rename the file too. It can be made to work using a *.di file if you really have to.
Re: Best practice and module declarations
On Thu, 15 Jul 2010 00:22:34 +0200, Jonathan M Davis wrote: I was wondering what the general consesus was (if there is one) on whether it's valuable to always put module declarations in each module. Obviously, if you need the module to have a name other than the file name, then you need to have the module declaration. However, is it necessarily desirable to have it when the module name matches the file name? Or would there even be a reason for it to be desirable _not_ to have the module declaration? I can't think of any particularly strong reasons to have it or not to have it. My first reaction is to just always use it, but thinking about it, I'm not sure that there's really much point if the file name and the module name already match. Does anyone have reasons why it would matter other than personal preference? - Jonathan M Davis From what I remember in TDPL: Can be used to rename a module if you have it in a different directory structure than how you use it. E.g. implementation and "headers" in separate folders. Can be used to rename module when a filename is not a valid D symbol. -Rory
Re: Best practice and module declarations
I was wondering what the general consesus was (if there is one) on whether >> it's >> valuable to always put module declarations in each module. >> > > I can't think of any particularly strong reasons to have it or not to have >> it. >> My first reaction is to just always use it, but thinking about it, I'm not >> sure >> that there's really much point if the file name and the module name >> already >> match. Does anyone have reasons why it would matter other than personal >> preference? >> > > I can see two reasons to use module declarations: - you can put documentation comments before the module declaration, to have them at the beginning of the docs. That's where you put general indications on the use of this module, and copyright/author/license indications. I quite like these module-level docs, personally. - it defines a new symbol, which you can use in template with alias parameters and __traits, like in __traits(allMembers, moduleName). If you're into compile-time introspection, that can be useful. (though maybe these symobols exist even without module decls, I don't know). Philippe
Re: Best practice and module declarations
On 15.07.2010 00:22, Jonathan M Davis wrote: I was wondering what the general consesus was (if there is one) on whether it's valuable to always put module declarations in each module. Obviously, if you need the module to have a name other than the file name, then you need to have the module declaration. However, is it necessarily desirable to have it when the module name matches the file name? Or would there even be a reason for it to be desirable _not_ to have the module declaration? I can't think of any particularly strong reasons to have it or not to have it. My first reaction is to just always use it, but thinking about it, I'm not sure that there's really much point if the file name and the module name already match. Does anyone have reasons why it would matter other than personal preference? Some of the D build tools complain if you don't use module declarations. And IIRC, modules in subdirectories (packages) need to have them. So I end up adding them for anything but single-file test programs.
Best practice and module declarations
I was wondering what the general consesus was (if there is one) on whether it's valuable to always put module declarations in each module. Obviously, if you need the module to have a name other than the file name, then you need to have the module declaration. However, is it necessarily desirable to have it when the module name matches the file name? Or would there even be a reason for it to be desirable _not_ to have the module declaration? I can't think of any particularly strong reasons to have it or not to have it. My first reaction is to just always use it, but thinking about it, I'm not sure that there's really much point if the file name and the module name already match. Does anyone have reasons why it would matter other than personal preference? - Jonathan M Davis
