Proposal: this.d

Bill Baxter dnewsgroup at billbaxter.com
Mon Sep 10 10:54:22 PDT 2007


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



More information about the Digitalmars-d mailing list