www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Proposal: this.d

reply Kirk McDonald <kirklin.mcdonald gmail.com> writes:
I brought this up in the "Modules vs Packages" thread, where it was 
received positively. I think it deserves its own thread.

Suppose you have a package, called pkg:

pkg/
   foo.d
   bar.d
   baz.d

It is useful to have a central import-point for the package. By 
convention, this is often called "pkg.all" or "pkg.pkg". It might look 
like this:

// pkg/all.d
module pkg.all;

public import foo : a, b;
public import bar : c, d;
//----

Then the user of your package would "import pkg.all;" and get your 
package's public API.

This is a common enough operation that I propose adding language support 
for it.

When a user says "import pkg;" (where pkg is a package), it should 
actually import a special module called "pkg/this.d". The name "this", 
being a keyword, cannot be used as a regular module name, and so there 
is no chance of it interfering with existing packages. It also evokes 
existing D syntax.

Our above example would look like this:

pkg/
   this.d
   foo.d
   bar.d
   baz.d

// pkg/this.d
module pkg;

public import foo : a, b;
public import bar : c, d;
//----

Saying "import pkg;" refers to this module.

The module declaration requires some explanation. Using either "module 
pkg;" or "module pkg.this;" might work, but either option is a little 
inconsistent. The important point here is that the name the module is 
imported as is different than its filename. (This is why the feature 
requires compiler support.)

Using "module pkg;" is to be preferred, since it is the name the module 
is imported as. It is not difficult to, given "import pkg;", determine 
that "pkg" is a directory, and look for a this.d inside it. Nor is it 
difficult to do the reverse: Given a file named "this.d", determine that 
it is the import point of a package.

There is one detail to go over. Suppose we say "import pkg;". Should we 
now be able to say "pkg.baz", even though the name "baz" is not 
publically imported inside of pkg/this.d? I would say no. In this 
respect, the this.d should act no differently than any other module. 
This is, if nothing else, the simplest behavior.

-- 
Kirk McDonald
http://kirkmcdonald.blogspot.com
Pyd: Connecting D and Python
http://pyd.dsource.org
Sep 09 2007
next sibling parent reply Downs <default_357-line yahoo.de> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kirk McDonald wrote:

 When a user says "import pkg;" (where pkg is a package), it should
 actually import a special module called "pkg/this.d". The name "this",
 being a keyword, cannot be used as a regular module name, and so there
 is no chance of it interfering with existing packages. It also evokes
 existing D syntax.
 


On the other hand, using all.d has the advantage of working better with
existing libraries (which often use this naming), as well as being more
obvious.
 --downs' 2¢
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG5GA1pEPJRr05fBERAqV5AJwIGMFIeAaK9wc0sBMR6WUXXDBqegCeNgAa
9R44FMK74jxQOja++VUkTwU=
=bia2
-----END PGP SIGNATURE-----
Sep 09 2007
parent Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Downs wrote:

 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
 Kirk McDonald wrote:
 

When a user says "import pkg;" (where pkg is a package), it should
actually import a special module called "pkg/this.d". The name "this",
being a keyword, cannot be used as a regular module name, and so there
is no chance of it interfering with existing packages. It also evokes
existing D syntax.


 
 
 On the other hand, using all.d has the advantage of working better with
 existing libraries (which often use this naming), as well as being more
 obvious.
  --downs' 2¢


Such packages would only have to add:

//this.d
module pkg;
public import pkg.all;

-- 
Kirk McDonald
http://kirkmcdonald.blogspot.com
Pyd: Connecting D and Python
http://pyd.dsource.org
Sep 09 2007
prev sibling next sibling parent Frank Benoit <keinfarbton googlemail.com> writes:
This is also very good, to have a defined place for the package
description in DDoc.
Sep 09 2007
prev sibling next sibling parent Daniel Keep <daniel.keep.lists gmail.com> writes:
Actually, I don't want this for the "pull in the whole API" feature.  I
can't count the number of times that I've done this:

module pkg.pkg;

For instance, take the DOM code I've been writing.  In an ideal world,
the user would only have to use "import xml.dom;" to get the various DOM
interfaces.  However, there are also several other modules that belong
inside of this namespace: xml.dom.util and xml.dom.conformance.
Suddenly, I can no longer use "xml.dom", and have to use "xml.dom.dom"
instead which is pretty damn ugly.

So, anyway.  ++vote;

	-- Daniel
Sep 09 2007
prev sibling next sibling parent reply kris <foo bar.com> writes:
Kirk McDonald wrote:

 I brought this up in the "Modules vs Packages" thread, where it was 
 received positively. I think it deserves its own thread.
 
 Suppose you have a package, called pkg:
 
 pkg/
   foo.d
   bar.d
   baz.d
 
 It is useful to have a central import-point for the package. By 
 convention, this is often called "pkg.all" or "pkg.pkg". It might look 
 like this:
 
 // pkg/all.d
 module pkg.all;
 
 public import foo : a, b;
 public import bar : c, d;
 //----
 
 Then the user of your package would "import pkg.all;" and get your 
 package's public API.
 
 This is a common enough operation that I propose adding language support 
 for it.
 
 When a user says "import pkg;" (where pkg is a package), it should 
 actually import a special module called "pkg/this.d". The name "this", 
 being a keyword, cannot be used as a regular module name, and so there 
 is no chance of it interfering with existing packages. It also evokes 
 existing D syntax.
 
 Our above example would look like this:
 
 pkg/
   this.d
   foo.d
   bar.d
   baz.d
 
 // pkg/this.d
 module pkg;
 
 public import foo : a, b;
 public import bar : c, d;
 //----
 
 Saying "import pkg;" refers to this module.
 
 The module declaration requires some explanation. Using either "module 
 pkg;" or "module pkg.this;" might work, but either option is a little 
 inconsistent. The important point here is that the name the module is 
 imported as is different than its filename. (This is why the feature 
 requires compiler support.)
 
 Using "module pkg;" is to be preferred, since it is the name the module 
 is imported as. It is not difficult to, given "import pkg;", determine 
 that "pkg" is a directory, and look for a this.d inside it. Nor is it 
 difficult to do the reverse: Given a file named "this.d", determine that 
 it is the import point of a package.
 
 There is one detail to go over. Suppose we say "import pkg;". Should we 
 now be able to say "pkg.baz", even though the name "baz" is not 
 publically imported inside of pkg/this.d? I would say no. In this 
 respect, the this.d should act no differently than any other module. 
 This is, if nothing else, the simplest behavior.
 


The issue with this is bloat, where (1) D is not at all good at dropping 
modules that are not actually needed (they'll often get linked anyway), 
and (2) the "where the feck are we?" syndrome where you've no idea what 
module a specific symbol might come from, or whether half of the imports 
are even required anymore due to code-motion or other edits. The latter 
is partly why "import x.*;" is considered rather poor form in Java land.

2c
Sep 09 2007
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
kris wrote:

 Kirk McDonald wrote:

 I brought this up in the "Modules vs Packages" thread, where it was 
 received positively. I think it deserves its own thread.

 Suppose you have a package, called pkg:

 pkg/
   foo.d
   bar.d
   baz.d

 It is useful to have a central import-point for the package. By 
 convention, this is often called "pkg.all" or "pkg.pkg". It might look 
 like this:

 // pkg/all.d
 module pkg.all;

 public import foo : a, b;
 public import bar : c, d;
 //----

 Then the user of your package would "import pkg.all;" and get your 
 package's public API.

 This is a common enough operation that I propose adding language 
 support for it.

 When a user says "import pkg;" (where pkg is a package), it should 
 actually import a special module called "pkg/this.d". The name "this", 
 being a keyword, cannot be used as a regular module name, and so there 
 is no chance of it interfering with existing packages. It also evokes 
 existing D syntax.

 Our above example would look like this:

 pkg/
   this.d
   foo.d
   bar.d
   baz.d

 // pkg/this.d
 module pkg;

 public import foo : a, b;
 public import bar : c, d;
 //----

 Saying "import pkg;" refers to this module.

 The module declaration requires some explanation. Using either "module 
 pkg;" or "module pkg.this;" might work, but either option is a little 
 inconsistent. The important point here is that the name the module is 
 imported as is different than its filename. (This is why the feature 
 requires compiler support.)

 Using "module pkg;" is to be preferred, since it is the name the 
 module is imported as. It is not difficult to, given "import pkg;", 
 determine that "pkg" is a directory, and look for a this.d inside it. 
 Nor is it difficult to do the reverse: Given a file named "this.d", 
 determine that it is the import point of a package.

 There is one detail to go over. Suppose we say "import pkg;". Should 
 we now be able to say "pkg.baz", even though the name "baz" is not 
 publically imported inside of pkg/this.d? I would say no. In this 
 respect, the this.d should act no differently than any other module. 
 This is, if nothing else, the simplest behavior.


 
 The issue with this is bloat, where (1) D is not at all good at dropping 
 modules that are not actually needed (they'll often get linked anyway), 
 and 
(2) the "where the feck are we?" syndrome where you've no idea what 
 module a specific symbol might come from, or whether half of the imports 
 are even required anymore due to code-motion or other edits. The latter 
 is partly why "import x.*;" is considered rather poor form in Java land.


You're talking there specifically about the question of whether pkg.baz 
should be automatically accessible, right?

--bb
Sep 09 2007
parent reply "Janice Caron" <caron800 googlemail.com> writes:
Content-Disposition: inline

For me, this is a simple naming thing ... but also a must!

As I see it, the problem (or at least, /a/ problem) is that if I have
modules:
x.a
x.b
x.c
x.d

Then I cannot simultaneously have a module called
x

(and have it be in the same package as x.a, etc.). And yet, that is often
exactly what I want to do. The "D-way" seems to be to name the package
x.x

but that's ugly, so, if naming a package
x.this

will allow me to refer to it as just x, then I'm all for it. I don't
actually care what goes /in/ the package though. That's up to whoever writes
it.
Sep 10 2007
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Janice Caron wrote:


 As I see it, the problem (or at least, /a/ problem) is that if I have 
 modules:
 x.a
 x.b
 x.c
 x.d
 
 Then I cannot simultaneously have a module called
 x
 
 (and have it be in the same package as x.a, etc.). And yet, that is 
 often exactly what I want to do. The "D-way" seems to be to name the package
 x.x


Yup, it is.


 but that's ugly, so, if naming a package
 x.this
 
 will allow me to refer to it as just x, then I'm all for it. 


Doesn't seem worth it, to me.

--anders
Sep 10 2007
parent reply "Janice Caron" <caron800 googlemail.com> writes:
Content-Disposition: inline


 Doesn't seem worth it, to me.


Well, consider that you initially create a package called
x

Now the module is imported by
import x;

and then, and some later stage, the project gets bigger, and you want to
throw extra source files into the mix. The desirable thing is to store all
those extra source files in a subdirectory called x, but that's not
permitted because x exists. So you move x into your new subdirectory - but
now it has to be refered to as x.x, so existing code which imports x breaks,
and you have to recompile it all -- which may not even be possible if x is a
published library, and the source code which imports it is out of your
hands.

However, if you could just rename the source file "this.d", and stick it
into the subdirectory, then you'd get the ability to add extra files to the
package *without breaking deployed code*

That seems worth it to me.
Sep 10 2007
next sibling parent Don Clugston <dac nospam.com.au> writes:
Janice Caron wrote:

     Doesn't seem worth it, to me.
 
 
 Well, consider that you initially create a package called
 x
 
 Now the module is imported by
 import x;
 
 and then, and some later stage, the project gets bigger, and you want to 
 throw extra source files into the mix. The desirable thing is to store 
 all those extra source files in a subdirectory called x, but that's not 
 permitted because x exists. So you move x into your new subdirectory - 
 but now it has to be refered to as x.x, so existing code which imports x 
 breaks, and you have to recompile it all -- which may not even be 
 possible if x is a published library, and the source code which imports 
 it is out of your hands.


eg, when x is std.math.

(This is why Tango has tango.math.Math, introducing an incompatibility with
Phobos).
Sep 10 2007
prev sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Janice Caron wrote:


     Doesn't seem worth it, to me.


 
 Well, consider that you initially create a package called
 x
 
 Now the module is imported by
 import x;
 
 and then, and some later stage, the project gets bigger, and you want to 
 throw extra source files into the mix. The desirable thing is to store 
 all those extra source files in a subdirectory called x, but that's not 
 permitted because x exists. So you move x into your new subdirectory - 
 but now it has to be refered to as x.x, so existing code which imports x 
 breaks, and you have to recompile it all -- which may not even be 
 possible if x is a published library, and the source code which imports 
 it is out of your hands.
 
 However, if you could just rename the source file " this.d", and stick 
 it into the subdirectory, then you'd get the ability to add extra files 
 to the package *without breaking deployed code*
 
 That seems worth it to me.


Fair enough. There is nothing contradictory between this "x" change
and how the "x.x" has traditionally worked so it's all up to Walter.

Guess I'm too used to C's libraries and frameworks, that use the x.x.
(such as wx.wx or sdl.sdl or gl.gl or al.al, or any Apple frameworks)

--anders
Sep 10 2007
prev sibling parent reply Jari-Matti =?ISO-8859-1?Q?M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
kris wrote:


 The issue with this is bloat, where (1) D is not at all good at dropping
 modules that are not actually needed (they'll often get linked anyway),


It's not only bloat in the resulting object files. Most modeling tools
assume that packages only consist of modules. IMO the concept of "hybrid"
package/module isn't worth the trouble. Well, unless D 2.0 is a competition
where the winner is the one with most proposals - let's wait who comes up
with the first integrated email reader :P


 and (2) the "where the feck are we?" syndrome where you've no idea what
 module a specific symbol might come from, or whether half of the imports
 are even required anymore due to code-motion or other edits. The latter
 is partly why "import x.*;" is considered rather poor form in Java land.


'import x.*' is still better than 'import x.all' because it's always up to
date and guarantees that it imports all modules in the package. A lot of
developer time is wasted creating more or less buggy non-portable scripts
for creating those all.d files - not to mention some write them manually.
Removing the fuss around importing was an acceptable compromise for me to
switch to Eclipse in Java development.
Sep 10 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Jari-Matti Mäkelä wrote:

 kris wrote:
 

 The issue with this is bloat, where (1) D is not at all good at dropping
 modules that are not actually needed (they'll often get linked anyway),


 
 It's not only bloat in the resulting object files. Most modeling tools
 assume that packages only consist of modules. IMO the concept of "hybrid"
 package/module isn't worth the trouble. Well, unless D 2.0 is a competition
 where the winner is the one with most proposals - let's wait who comes up
 with the first integrated email reader :P
 

 and (2) the "where the feck are we?" syndrome where you've no idea what
 module a specific symbol might come from, or whether half of the imports
 are even required anymore due to code-motion or other edits. The latter
 is partly why "import x.*;" is considered rather poor form in Java land.


 
 'import x.*' is still better than 'import x.all' because it's always up to
 date and guarantees that it imports all modules in the package. A lot of
 developer time is wasted creating more or less buggy non-portable scripts
 for creating those all.d files - not to mention some write them manually.
 Removing the fuss around importing was an acceptable compromise for me to
 switch to Eclipse in Java development.


I think the point was that importing all modules, however you accomplish 
it, makes it difficult for people reading the code to figure out where 
symbols originate and, in current D, increases bloat in the final 
executable.  .* has the added detriment, though, of also importing 
modules that are only intended as part of the private implementation of 
a package, or which are just old test files lying around etc.

In Python, probably the most common usage of the __init__.py module is 
as a place to stuff package-specific documentation.  It's also supposed 
to list, but not import, the modules that should be imported by an 
"import package.*".  This solves the problem of .* pulling in unrelated 
cruft.  (Python people still recommend against using .* imports, though)

--bb
Sep 10 2007
parent reply Jari-Matti =?ISO-8859-1?Q?M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
Bill Baxter wrote:


 Jari-Matti Mäkelä wrote:

 kris wrote:
 

 The issue with this is bloat, where (1) D is not at all good at dropping
 modules that are not actually needed (they'll often get linked anyway),


 
 It's not only bloat in the resulting object files. Most modeling tools
 assume that packages only consist of modules. IMO the concept of "hybrid"
 package/module isn't worth the trouble. Well, unless D 2.0 is a
 competition where the winner is the one with most proposals - let's wait
 who comes up with the first integrated email reader :P
 

 and (2) the "where the feck are we?" syndrome where you've no idea what
 module a specific symbol might come from, or whether half of the imports
 are even required anymore due to code-motion or other edits. The latter
 is partly why "import x.*;" is considered rather poor form in Java land.


 
 'import x.*' is still better than 'import x.all' because it's always up
 to date and guarantees that it imports all modules in the package. A lot
 of developer time is wasted creating more or less buggy non-portable
 scripts for creating those all.d files - not to mention some write them
 manually. Removing the fuss around importing was an acceptable compromise
 for me to switch to Eclipse in Java development.


 
 I think the point was that importing all modules, however you accomplish
 it, makes it difficult for people reading the code to figure out where
 symbols originate


True, but you could say all imports cause some sorts of difficulties reading
the code without proper tool support. Figuring out things by looking at the
code in Notepad quite probably takes more time than with a modern IDE in
which moving the mouse on an unknown symbol shows up a nicely colored popup
with formatted docs, declaration location etc. (+ a hotkey jumps to the
declaration)


 and, in current D, increases bloat in the final executable.
 .* has the added detriment, though, of also importing 
 modules that are only intended as part of the private implementation of
 a package, or which are just old test files lying around etc.
 
 In Python, probably the most common usage of the __init__.py module is
 as a place to stuff package-specific documentation.  It's also supposed
 to list, but not import, the modules that should be imported by an
 "import package.*".  This solves the problem of .* pulling in unrelated
 cruft.


Agreed. I didn't say .* was perfect, it just solves some problems. I could
say test files and other private implementation should be perhaps in some
nested package, but that would make the package modifier partly useless.
Package level documentation would be a very nice thing, but on the other
hand if the compiler would allow e.g. declarations inside this.d, some
tools would need special support for D. Maybe this is a limitation in the
tools?
Sep 10 2007
parent reply Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Jari-Matti Mäkelä wrote:

 Bill Baxter wrote:

In Python, probably the most common usage of the __init__.py module is
as a place to stuff package-specific documentation.  It's also supposed
to list, but not import, the modules that should be imported by an
"import package.*".  This solves the problem of .* pulling in unrelated
cruft.


 


(The Python syntax is actually "from package import *", but I'm just 
being pedantic by pointing that out.)


 
 Agreed. I didn't say .* was perfect, it just solves some problems. I could
 say test files and other private implementation should be perhaps in some
 nested package, but that would make the package modifier partly useless.
 Package level documentation would be a very nice thing, but on the other
 hand if the compiler would allow e.g. declarations inside this.d, some
 tools would need special support for D. Maybe this is a limitation in the
 tools?


Why wouldn't declarations be allowed in this.d? It's just another module 
with a curious way of importing it.

-- 
Kirk McDonald
http://kirkmcdonald.blogspot.com
Pyd: Connecting D and Python
http://pyd.dsource.org
Sep 10 2007
parent Jari-Matti =?ISO-8859-1?Q?M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
Kirk McDonald wrote:


 Why wouldn't declarations be allowed in this.d? It's just another module
 with a curious way of importing it.


You're right - it's consistent in that way. It's just that at least UML
tools seem to be geared towards Java style development. One can fake top
level modules with classes to some extend, but I just realized this.d could
make it look a bit messy. I have to think about it more.
Sep 10 2007
prev sibling next sibling parent reply Tomas Lindquist Olsen <tomas famolsen.dk> writes:
Kirk McDonald wrote:


 I brought this up in the "Modules vs Packages" thread, where it was
 received positively. I think it deserves its own thread.
 
 Suppose you have a package, called pkg:
 
 pkg/
    foo.d
    bar.d
    baz.d
 
 It is useful to have a central import-point for the package. By
 convention, this is often called "pkg.all" or "pkg.pkg". It might look
 like this:
 
 // pkg/all.d
 module pkg.all;
 
 public import foo : a, b;
 public import bar : c, d;
 //----
 
 Then the user of your package would "import pkg.all;" and get your
 package's public API.
 
 This is a common enough operation that I propose adding language support
 for it.
 
 When a user says "import pkg;" (where pkg is a package), it should
 actually import a special module called "pkg/this.d". The name "this",
 being a keyword, cannot be used as a regular module name, and so there
 is no chance of it interfering with existing packages. It also evokes
 existing D syntax.
 
 Our above example would look like this:
 
 pkg/
    this.d
    foo.d
    bar.d
    baz.d
 
 // pkg/this.d
 module pkg;
 
 public import foo : a, b;
 public import bar : c, d;
 //----
 
 Saying "import pkg;" refers to this module.
 
 The module declaration requires some explanation. Using either "module
 pkg;" or "module pkg.this;" might work, but either option is a little
 inconsistent. The important point here is that the name the module is
 imported as is different than its filename. (This is why the feature
 requires compiler support.)
 
 Using "module pkg;" is to be preferred, since it is the name the module
 is imported as. It is not difficult to, given "import pkg;", determine
 that "pkg" is a directory, and look for a this.d inside it. Nor is it
 difficult to do the reverse: Given a file named "this.d", determine that
 it is the import point of a package.
 
 There is one detail to go over. Suppose we say "import pkg;". Should we
 now be able to say "pkg.baz", even though the name "baz" is not
 publically imported inside of pkg/this.d? I would say no. In this
 respect, the this.d should act no differently than any other module.
 This is, if nothing else, the simplest behavior.
 


I would like to see:
import package x;

The package keyword is probably one of the least used keywords in D (I guess
because it's buggy) and this way there is no doubt what is happening.

My $0.02
Sep 10 2007
next sibling parent Alexander Panek <a.panek brainsware.org> writes:
Tomas Lindquist Olsen wrote:

 I would like to see:
 import package x;


Yes, yes, yes!

Ingenius.
Sep 10 2007
prev sibling parent Carlos Santander <csantander619 gmail.com> writes:
Tomas Lindquist Olsen escribió:

 
 I would like to see:
 import package x;
 
 The package keyword is probably one of the least used keywords in D (I guess
 because it's buggy) and this way there is no doubt what is happening.
 
 My $0.02


I like this one, as long as it doesn't mean "import x.*;"
It would only open the door to having x.d and x/ at the same level.
IMHO.

-- 
Carlos Santander Bernal
Sep 10 2007
prev sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Kirk McDonald wrote:

 I brought this up in the "Modules vs Packages" thread, where it was 
 received positively. I think it deserves its own thread.
 
 Suppose you have a package, called pkg:
 
 pkg/
   foo.d
   bar.d
   baz.d
 
 It is useful to have a central import-point for the package. By 
 convention, this is often called "pkg.all" or "pkg.pkg". It might look 
 like this:
 
 // pkg/all.d
 module pkg.all;
 
 public import foo : a, b;
 public import bar : c, d;
 //----
 
 Then the user of your package would "import pkg.all;" and get your 
 package's public API.
 
 This is a common enough operation that I propose adding language support 
 for it.
 
 When a user says "import pkg;" (where pkg is a package), it should 
 actually import a special module called "pkg/this.d". The name "this", 
 being a keyword, cannot be used as a regular module name, and so there 
 is no chance of it interfering with existing packages. It also evokes 
 existing D syntax.
 
 Our above example would look like this:
 
 pkg/
   this.d
   foo.d
   bar.d
   baz.d
 
 // pkg/this.d
 module pkg;
 
 public import foo : a, b;
 public import bar : c, d;
 //----
 
 Saying "import pkg;" refers to this module.
 
 The module declaration requires some explanation. Using either "module 
 pkg;" or "module pkg.this;" might work, but either option is a little 
 inconsistent. The important point here is that the name the module is 
 imported as is different than its filename. (This is why the feature 
 requires compiler support.)
 
 Using "module pkg;" is to be preferred, since it is the name the module 
 is imported as. It is not difficult to, given "import pkg;", determine 
 that "pkg" is a directory, and look for a this.d inside it. Nor is it 
 difficult to do the reverse: Given a file named "this.d", determine that 
 it is the import point of a package.
 
 There is one detail to go over. Suppose we say "import pkg;". Should we 
 now be able to say "pkg.baz", even though the name "baz" is not 
 publically imported inside of pkg/this.d? I would say no. In this 
 respect, the this.d should act no differently than any other module. 
 This is, if nothing else, the simplest behavior.
 


One thought that's been slowing nagging me is that is that 'this.d' 
isn't really analogous to the other situations in which 'this' is used in d.

It just gelled for me now as I was trying and failing to call a function 
called 'module' in a module named 'module'.

We have a module 'this' but it's used for something bigger than just 
side-stepping name collision problems.  We don't actually have a way to 
sidestep the module name == function name problem as far as I know.  But 
it seems like the solution to that should have the same "look and feel" 
as the solution for not being able to have a module with the same name 
as a package.

Also given that fact that module 'this' is a thing that runs once if a 
given module is used, it seems logical that package 'this' would be 
something that gets _imported_ once if any module in that package is 
used.  Which isn't quite what we're proposing here.

--bb
Sep 10 2007