Proposal: this.d

[Bill Baxter]

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