Thread overview | |||||||
---|---|---|---|---|---|---|---|
|
July 15, 2013 module name inference | ||||
---|---|---|---|---|
| ||||
Attachments:
| currently when no module declaration is given, the module name is given by the path base name (__FILE__.baseName.stripExtension). This is rarely useful (as soon as one has modules nested in packages). Why not instead infer the module name from the relative path of __FILE__ with respect to the first directory in the import list in which __FILE__ is found: ---- src/foo/bar.d: // infers 'module foo.bar;' instead of 'module bar;' void barfun(){} ---- ---- src/main.d: import foo.bar; void main(){} ---- dmd -Isrc src/main.d |
July 15, 2013 Re: module name inference | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timothee Cour | On Monday, 15 July 2013 at 15:45:47 UTC, Timothee Cour wrote:
> ---- src/foo/bar.d:
> // infers 'module foo.bar;' instead of 'module bar;'
> void barfun(){}
> ----
>
> ---- src/main.d:
> import foo.bar;
> void main(){}
> ----
>
> dmd -Isrc src/main.d
And what if I compile it like this?
dmd -c src/foo/bar.d
dmd -c -Isrc src/main.d
// link later
I don't think this can work in general.
|
July 15, 2013 Re: module name inference | ||||
---|---|---|---|---|
| ||||
Posted in reply to Peter Alexander Attachments:
| On Mon, Jul 15, 2013 at 9:55 AM, Peter Alexander < peter.alexander.au@gmail.com> wrote:
> On Monday, 15 July 2013 at 15:45:47 UTC, Timothee Cour wrote:
>
>> ---- src/foo/bar.d:
>> // infers 'module foo.bar;' instead of 'module bar;'
>> void barfun(){}
>> ----
>>
>> ---- src/main.d:
>> import foo.bar;
>> void main(){}
>> ----
>>
>> dmd -Isrc src/main.d
>>
>
> And what if I compile it like this?
>
> dmd -c src/foo/bar.d
> dmd -c -Isrc src/main.d
> // link later
>
> I don't think this can work in general.
>
Yes I thought about that case. It would still work by passing the same -I
flags:
dmd -c -Isrc src/foo/bar.d
dmd -c -Isrc src/main.d
// link later
When a file would be fully specified on the command line as above, the -I flag would specify the offset from which to compute the relative path. I think it's a simple rule that makes code more DRY and easy to refactor.
|
July 15, 2013 Re: module name inference | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timothee Cour | On 2013-07-15 17:45, Timothee Cour wrote: > currently when no module declaration is given, the module name is given > by the path base name (__FILE__.baseName.stripExtension). > This is rarely useful (as soon as one has modules nested in packages). > Why not instead infer the module name from the relative path of __FILE__ > with respect to the first directory in the import list in which __FILE__ > is found: > > ---- src/foo/bar.d: > // infers 'module foo.bar;' instead of 'module bar;' > void barfun(){} > ---- > > ---- src/main.d: > import foo.bar; > void main(){} > ---- > > dmd -Isrc src/main.d Why not just specify a module declaration? I always do that. -- /Jacob Carlborg |
July 15, 2013 Re: module name inference | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg Attachments:
| On Mon, Jul 15, 2013 at 11:31 AM, Jacob Carlborg <doob@me.com> wrote:
> On 2013-07-15 17:45, Timothee Cour wrote:
>
>> currently when no module declaration is given, the module name is given
>> by the path base name (__FILE__.baseName.**stripExtension).
>> This is rarely useful (as soon as one has modules nested in packages).
>> Why not instead infer the module name from the relative path of __FILE__
>> with respect to the first directory in the import list in which __FILE__
>> is found:
>>
>> ---- src/foo/bar.d:
>> // infers 'module foo.bar;' instead of 'module bar;'
>> void barfun(){}
>> ----
>>
>> ---- src/main.d:
>> import foo.bar;
>> void main(){}
>> ----
>>
>> dmd -Isrc src/main.d
>>
>
> Why not just specify a module declaration? I always do that.
I do so as well precisely because of the current module name inference rule. But with this proposal, it would become optional, making the code more DRY and easier to refactor. Especially useful during development phase.
|
Copyright © 1999-2021 by the D Language Foundation