Proposal: this.d

[Jari-Matti Mäkelä]

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?