Importing packages

Chris Nicholson-Sauls ibisbasenji at gmail.com
Sat Oct 28 00:02:50 PDT 2006


Kyle Furlong wrote:
> Bill Baxter wrote:
> 
>> Mart Roosmaa wrote:
>>
>>> Hello everybody,
>>>
>>> I am quite new to D and when learning how the packages and modules
>>> worked, it seemed strange to me that if one wanted to import whole
>>> packages one would have to create a module (for example a module called
>>> "All") and do public imports of every other module in the package.
>>>
>>> While this approach works, it's quite painful to keep that module up to
>>> date, as people tend to forget to update the central module doing the
>>> public imports.
>>>
>>> Now, I propose to extend the import declaration so that if only a
>>> package is given, it imports all modules in that package.
>>> For example "import std.c;" would import std.c.fenv, std.c.math,
>>> std.c.process, std.c.stdargs, etc modules.
>>>
>>> This approach would keep the code a bit easier to maintain as one
>>> wouldn't have to update the public imports module all the time.
>>>
>>> What do you think? Could it be implemented in DMD?
>>
>>
>> What do you do about modules that really are intended to be 
>> implementation details rather than end-user code (aka private module)? 
>> What about packages containing a hierarchy of subpackages - do you 
>> import those recursively?
>>
>> I would be more agreeable to the proposal if "import std.c" would be 
>> synononymous with "import std.c.all if it exists, otherwise import 
>> everything you can find under std.c".  That way the package 
>> maintainers still get to decide what consitutes 'all visible modules' 
>> of the package if they care to.
>>
>> --bb
> 
> 
> Sensible.

Agreed; although one could easily enough add 'package:' to the top of one's private 
modules, this comes at the price of symbols being unavailable to subpackages (in my 
opinion, this is a shortcoming of the package protection attribute).  Also, this may or 
may not play well with the presence of other protection attributes in the code (such as 
private members, or some single public class/interface).

-- Chris Nicholson-Sauls



More information about the Digitalmars-d mailing list