www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - module name inference

reply Timothee Cour <thelastmammoth gmail.com> writes:
--e89a8fb1f5223621e704e18ec05e
Content-Type: text/plain; charset=ISO-8859-1

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

--e89a8fb1f5223621e704e18ec05e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

currently when no module declaration is given, the module name is given by =
the path base name (__FILE__.baseName.stripExtension).<div>This is rarely u=
seful (as soon as one has modules nested in packages).<br><div>Why not inst=
ead infer the module name from the relative path of __FILE__ with respect t=
o the first directory in the import list in which __FILE__ is found:</div>
</div><div><br></div><div><div>---- src/foo/bar.d:</div><div>// infers &#39=
;module foo.bar;&#39; instead of &#39;module bar;&#39;</div><div>void barfu=
n(){}</div><div>----</div></div><div><br></div><div><div>---- src/main.d:</=
div>
<div>import foo.bar;</div><div>void main(){}</div><div>----</div></div><div=
<br></div><div>dmd -Isrc src/main.d</div>

--e89a8fb1f5223621e704e18ec05e--
Jul 15 2013
next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
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.
Jul 15 2013
prev sibling next sibling parent Timothee Cour <thelastmammoth gmail.com> writes:
--089e015381bc31054c04e190a6e3
Content-Type: text/plain; charset=ISO-8859-1

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. --089e015381bc31054c04e190a6e3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Jul 15, 2013 at 9:55 AM, Peter Alexander <span dir=3D"ltr">&lt;<a h= ref=3D"mailto:peter.alexander.au gmail.com" target=3D"_blank">peter.alexand= er.au gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_quote"><blockq= uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc = solid;padding-left:1ex"> <div class=3D"im">On Monday, 15 July 2013 at 15:45:47 UTC, Timothee Cour wr= ote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> ---- src/foo/bar.d:<br> // infers &#39;module foo.bar;&#39; instead of &#39;module bar;&#39;<br> void barfun(){}<br> ----<br> <br> ---- src/main.d:<br> import foo.bar;<br> void main(){}<br> ----<br> <br> dmd -Isrc src/main.d<br> </blockquote> <br></div> And what if I compile it like this?<br> <br> dmd -c src/foo/bar.d<br> dmd -c -Isrc src/main.d<br> // link later<br> <br> I don&#39;t think this can work in general.<br> </blockquote></div><div><br></div>Yes I thought about that case. It would s= till work by passing the same -I flags:<br><div>dmd -c -Isrc src/foo/bar.d<= /div><div>dmd -c -Isrc src/main.d<br>// link later<br></div><div><br></div> <div>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&#39;s a simple rule that makes code more DRY and easy to refacto= r.</div> --089e015381bc31054c04e190a6e3--
Jul 15 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
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
Jul 15 2013
prev sibling parent Timothee Cour <thelastmammoth gmail.com> writes:
--089e013a100a6010fe04e1915e45
Content-Type: text/plain; charset=ISO-8859-1

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. --089e013a100a6010fe04e1915e45 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Jul 15, 2013 at 11:31 AM, Jacob Carlborg <span dir=3D"ltr">&lt;<a h= ref=3D"mailto:doob me.com" target=3D"_blank">doob me.com</a>&gt;</span> wro= te:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On 2013-07-15 17:45, Timothee Cour wrote:<br> </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"><div class=3D"im"> currently when no module declaration is given, the module name is given<br> by the path base name (__FILE__.baseName.<u></u>stripExtension).<br> This is rarely useful (as soon as one has modules nested in packages).<br> Why not instead infer the module name from the relative path of __FILE__<br=


<br></div><div class=3D"im"> ---- src/foo/bar.d:<br> // infers &#39;module foo.bar;&#39; instead of &#39;module bar;&#39;<br> void barfun(){}<br> ----<br> <br> ---- src/main.d:<br> import foo.bar;<br> void main(){}<br> ----<br> <br> dmd -Isrc src/main.d<br> </div></blockquote> <br> Why not just specify a module declaration? I always do that.</blockquote><d= iv><br></div><div>I do so as well precisely because of the current module n= ame inference rule. But with this proposal, it would become optional, makin= g the code more DRY and easier to refactor. Especially useful during develo= pment phase.</div> </div> --089e013a100a6010fe04e1915e45--
Jul 15 2013