www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Make imports private by default

reply Frank Benoit <benoit__ __tionex.de> writes:
There was a posting of Tyro
http://www.digitalmars.com/d/archives/digitalmars/D/11081.html

Most ppl seconded that.

The problem is, that D does not work if you use non-private imports all
the time. Suddenly there are conflicts.

A public import make the imported module part of this modules interface.
This can (and should) be made public explicitely.
Apr 13 2006
next sibling parent reply "Derek Parnell" <derek psych.ward> writes:
On Thu, 13 Apr 2006 20:42:14 +1000, Frank Benoit <benoit__ __tionex.de>  
wrote:

 There was a posting of Tyro
 http://www.digitalmars.com/d/archives/digitalmars/D/11081.html

 Most ppl seconded that.

 The problem is, that D does not work if you use non-private imports all
 the time. Suddenly there are conflicts.

 A public import make the imported module part of this modules interface.
 This can (and should) be made public explicitely.

I think the reason is that all other unadorned symbols in a module are public so therefore why make an exception with imports. If that is the reason, I think it is not a good one. It assumes that consistency is always a good thing, that new programmers to D are too simple-minded to remember this 'exception', that C/C++ programmers are too simple-minded and thus will get confused, that remembering to type "private { import ... }" is easier to do that remembering (if this is fixed) that imports are already private, that porting C programs is going to be the major activity of D coders in the future, ... Yes, I do think this is a foolish, bureaucratic, simplistic decision to make imports public by default. Who here is going to be seriously affected if imports are made private by default? -- Derek Parnell Melbourne, Australia
Apr 13 2006
next sibling parent Lionello Lunesu <lio lunesu.remove.com> writes:
I agree with the OP: imports should not be public.

 Who here is going to be seriously affected if imports are made private 
 by default?

How about making imports "package" by default? That is, only accessible to modules in the same package. Might be a nice compromise between "public" and "private". L.
Apr 13 2006
prev sibling parent Norbert Nemec <Norbert Nemec-online.de> writes:
I fully agree. The rule "everything in a module is public by default" is
just too simple. A "default" should always consider what is the best
solution if people are too lazy to think about the issue.

Just consider the two options:

* "imports public by default": many libraries will export tons of
garbage, just because the authors were lazy. The clear structure of a
library will be washed out because, to the user, every symbol is everywhere.

* "import private by default": a module will usually export only a small
and distinct set of symbols, so you can easily pick those modules that
you actually need with minimal risk of conflicts. As an alternative, a
large library can always offer "collective modules" that just consist of
a list of public imports.

So, instead of just sticking to simple principles, the decision should
be made based on the effect on the language as a whole.



Derek Parnell wrote:
 On Thu, 13 Apr 2006 20:42:14 +1000, Frank Benoit <benoit__ __tionex.de> 
 wrote:
 
 There was a posting of Tyro
 http://www.digitalmars.com/d/archives/digitalmars/D/11081.html

 Most ppl seconded that.

 The problem is, that D does not work if you use non-private imports all
 the time. Suddenly there are conflicts.

 A public import make the imported module part of this modules interface.
 This can (and should) be made public explicitely.

I think the reason is that all other unadorned symbols in a module are public so therefore why make an exception with imports. If that is the reason, I think it is not a good one. It assumes that consistency is always a good thing, that new programmers to D are too simple-minded to remember this 'exception', that C/C++ programmers are too simple-minded and thus will get confused, that remembering to type "private { import ... }" is easier to do that remembering (if this is fixed) that imports are already private, that porting C programs is going to be the major activity of D coders in the future, ... Yes, I do think this is a foolish, bureaucratic, simplistic decision to make imports public by default. Who here is going to be seriously affected if imports are made private by default?

Apr 13 2006
prev sibling next sibling parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
Frank Benoit wrote:
 There was a posting of Tyro
 http://www.digitalmars.com/d/archives/digitalmars/D/11081.html
 
 Most ppl seconded that.
 
 The problem is, that D does not work if you use non-private imports all
 the time. Suddenly there are conflicts.
 
 A public import make the imported module part of this modules interface.
 This can (and should) be made public explicitely.
 

I never understood why people use private imports .. just what the hell is the point? Please give real, concrete examples, not just theories/talk. "Clogging up the namespace" doesn't say anything meaningful to me.
Apr 13 2006
next sibling parent Frank Benoit <benoit__ __tionex.de> writes:
 I never understood why people use private imports .. just what the hell
 is the point?
 Please give real, concrete examples, not just theories/talk.
 "Clogging up the namespace" doesn't say anything meaningful to me.

If you do not care about what is imported, why not make an import *; by default and everything is OK? No, thats not true. E.g. you make an own class Thread. If every module uses public imports, you will have a good chance std.thread is indirectly imported. So you have to use full qualified names all the time. If not it can happen you use the wrong Thread class. Only because you imported for e.g. std.math (don't know, sort of example) which imports std.stdio, which imports ..... std.thread. You know what i am trying to say? The other thing is, that the compiler has this problem with ambiguity of indirectly imported symbols. Well, last time I run into that problem in december 05. After that i learned to use private imports. If you have existing code and make a refactoring in private methods and decide to remove imports, you can get compile errors in completely other modules. This is because these module never imported the needed module, instead they were imported indirectly. I personally want to know, what is imported from my module.
Apr 13 2006
prev sibling next sibling parent reply Don Clugston <dac nospam.com.au> writes:
Hasan Aljudy wrote:
 Frank Benoit wrote:
 There was a posting of Tyro
 http://www.digitalmars.com/d/archives/digitalmars/D/11081.html

 Most ppl seconded that.

 The problem is, that D does not work if you use non-private imports all
 the time. Suddenly there are conflicts.

 A public import make the imported module part of this modules interface.
 This can (and should) be made public explicitely.

I never understood why people use private imports .. just what the hell is the point? Please give real, concrete examples, not just theories/talk. "Clogging up the namespace" doesn't say anything meaningful to me.

If module foo publicly imports std.date, then any module which imports foo cannot use std.string.format without colliding with std.date.format. This has bitten me several times already.
Apr 13 2006
parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
Don Clugston wrote:
 Hasan Aljudy wrote:
 
 Frank Benoit wrote:

 There was a posting of Tyro
 http://www.digitalmars.com/d/archives/digitalmars/D/11081.html

 Most ppl seconded that.

 The problem is, that D does not work if you use non-private imports all
 the time. Suddenly there are conflicts.

 A public import make the imported module part of this modules interface.
 This can (and should) be made public explicitely.

I never understood why people use private imports .. just what the hell is the point? Please give real, concrete examples, not just theories/talk. "Clogging up the namespace" doesn't say anything meaningful to me.

If module foo publicly imports std.date, then any module which imports foo cannot use std.string.format without colliding with std.date.format. This has bitten me several times already.

OK, this seems to be a valid problem, however, even if imports become private by default, there's nothing stopping foo from publicly importing std.date and std.string at the same time. I think what you really want, is to import foo in such a way that you don't import what foo imports, not even what foo publicly imports. So, it's better to have another kind of import .. an import that only imports things directly defined in module foo. shallow import foo; OR direct import foo; or something like that ..
Apr 13 2006
parent reply clayasaurus <clayasaurus gmail.com> writes:
Hasan Aljudy wrote:
 Don Clugston wrote:
 Hasan Aljudy wrote:

 Frank Benoit wrote:

 There was a posting of Tyro
 http://www.digitalmars.com/d/archives/digitalmars/D/11081.html

 Most ppl seconded that.

 The problem is, that D does not work if you use non-private imports all
 the time. Suddenly there are conflicts.

 A public import make the imported module part of this modules 
 interface.
 This can (and should) be made public explicitely.

I never understood why people use private imports .. just what the hell is the point? Please give real, concrete examples, not just theories/talk. "Clogging up the namespace" doesn't say anything meaningful to me.

If module foo publicly imports std.date, then any module which imports foo cannot use std.string.format without colliding with std.date.format. This has bitten me several times already.

OK, this seems to be a valid problem, however, even if imports become private by default, there's nothing stopping foo from publicly importing std.date and std.string at the same time.

But at least the error is in the file the dmd compiler says it is, the error for the above problem will be almost impossible for a maintainer to find in a large project.
Apr 13 2006
parent clayasaurus <clayasaurus gmail.com> writes:
clayasaurus wrote:
 Hasan Aljudy wrote:
 Don Clugston wrote:
 Hasan Aljudy wrote:

 Frank Benoit wrote:

 There was a posting of Tyro
 http://www.digitalmars.com/d/archives/digitalmars/D/11081.html

 Most ppl seconded that.

 The problem is, that D does not work if you use non-private imports 
 all
 the time. Suddenly there are conflicts.

 A public import make the imported module part of this modules 
 interface.
 This can (and should) be made public explicitely.

I never understood why people use private imports .. just what the hell is the point? Please give real, concrete examples, not just theories/talk. "Clogging up the namespace" doesn't say anything meaningful to me.

If module foo publicly imports std.date, then any module which imports foo cannot use std.string.format without colliding with std.date.format. This has bitten me several times already.

OK, this seems to be a valid problem, however, even if imports become private by default, there's nothing stopping foo from publicly importing std.date and std.string at the same time.

But at least the error is in the file the dmd compiler says it is, the error for the above problem will be almost impossible for a maintainer to find in a large project.

Nevermind, I thought you were trying to illustrate a different problem :-/
Apr 13 2006
prev sibling next sibling parent Hong <Hong_member pathlink.com> writes:
What Frank Benoit wrote seems perfectly understandable for most people. Poluting
the namespace is just as meaningful as anything you can get.

In article <e1lct1$25an$1 digitaldaemon.com>, Hasan Aljudy says...
Frank Benoit wrote:
 There was a posting of Tyro
 http://www.digitalmars.com/d/archives/digitalmars/D/11081.html
 
 Most ppl seconded that.
 
 The problem is, that D does not work if you use non-private imports all
 the time. Suddenly there are conflicts.
 
 A public import make the imported module part of this modules interface.
 This can (and should) be made public explicitely.
 

I never understood why people use private imports .. just what the hell is the point? Please give real, concrete examples, not just theories/talk. "Clogging up the namespace" doesn't say anything meaningful to me.

Apr 13 2006
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
Hasan Aljudy wrote:
 Frank Benoit wrote:
 There was a posting of Tyro
 http://www.digitalmars.com/d/archives/digitalmars/D/11081.html

 Most ppl seconded that.

 The problem is, that D does not work if you use non-private imports all
 the time. Suddenly there are conflicts.

 A public import make the imported module part of this modules interface.
 This can (and should) be made public explicitely.

I never understood why people use private imports .. just what the hell is the point? Please give real, concrete examples, not just theories/talk. "Clogging up the namespace" doesn't say anything meaningful to me.

It's similar to why things can be made private at class scope. Private imports are akin to implementation details--a user of the module shouldn't know or care about them. Public symbols exposed by a module are essentially that module's interface, in much the same was as public symbols of a class are the classes interface. If it isn't something specifically intended for use then it shouldn't be public. Sean
Apr 13 2006
parent Dan <Dan_member pathlink.com> writes:
 I never understood why people use private imports .. just what the hell 
 is the point?
 Please give real, concrete examples, not just theories/talk.
 "Clogging up the namespace" doesn't say anything meaningful to me.

It's similar to why things can be made private at class scope. Private imports are akin to implementation details--a user of the module shouldn't know or care about them. Public symbols exposed by a module are essentially that module's interface, in much the same was as public symbols of a class are the classes interface. If it isn't something specifically intended for use then it shouldn't be public.

I've been doing a fair bit of "aspect oriented" programming. Basically, I'm taking 100k of code and turning it sideways - instead of the methods, class, and arrays all in one file I'm putting all the arrays in one file, splitting groups of methods into separate files, and putting all the 'classes' in a file. It will make the program dramatically easier to understand and thus maintain. However, it necessitates exposing many things across modules. For this purpose, I'm using private imports to get exactly the files I want. It's my opinion though that he's right. For most cases, you should default your CODE to private, not the import.
Apr 14 2006
prev sibling next sibling parent reply Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Frank Benoit wrote:
 There was a posting of Tyro
 http://www.digitalmars.com/d/archives/digitalmars/D/11081.html
 
 Most ppl seconded that.
 
 The problem is, that D does not work if you use non-private imports all
 the time. Suddenly there are conflicts.
 
 A public import make the imported module part of this modules interface.
 This can (and should) be made public explicitely.
 

Totally agree. As for the consistency issue, it was said private imports by default where worth the small inconsistency (of everything else being public). Actually I disagree with that at the premise level: I don't think it would be an inconsistency at all. Imports are not members of the module, as they do not even define a new entity. They are not a "part of" the module, they are more like a characteristic of it. Further indication is that there is no "package import". And even "public import", would it be of any significant use? (Of course one could think of imports as the definition of a set of aliases, but really, I would think that's an unadequate and contrived conceptualization) -- Bruno Medeiros - CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Apr 13 2006
next sibling parent reply "Chris Miller" <chris dprogramming.com> writes:
On Thu, 13 Apr 2006 12:29:27 -0400, Bruno Medeiros  
<brunodomedeirosATgmail SPAM.com> wrote:

 Frank Benoit wrote:
 There was a posting of Tyro
 http://www.digitalmars.com/d/archives/digitalmars/D/11081.html
  Most ppl seconded that.
  The problem is, that D does not work if you use non-private imports all
 the time. Suddenly there are conflicts.
  A public import make the imported module part of this modules  
 interface.
 This can (and should) be made public explicitely.

Totally agree. As for the consistency issue, it was said private imports by default where worth the small inconsistency (of everything else being public). Actually I disagree with that at the premise level: I don't think it would be an inconsistency at all. Imports are not members of the module, as they do not even define a new entity. They are not a "part of" the module, they are more like a characteristic of it. Further indication is that there is no "package import". And even "public import", would it be of any significant use? (Of course one could think of imports as the definition of a set of aliases, but really, I would think that's an unadequate and contrived conceptualization)

Good point. Perhaps the current private import should be the default, and to achieve the current public import, something else could be used, such as "static import" ? Since the majority of imports are private, and even some public ones should have been private, I don't think this change would be difficult. The most common case would then be: * Default, logical choice; * Easier to type; * Better looking code;
Apr 13 2006
parent reply kris <foo bar.com> writes:
Chris Miller wrote:
 On Thu, 13 Apr 2006 12:29:27 -0400, Bruno Medeiros  
 <brunodomedeirosATgmail SPAM.com> wrote:
 
 Frank Benoit wrote:

 There was a posting of Tyro
 http://www.digitalmars.com/d/archives/digitalmars/D/11081.html
  Most ppl seconded that.
  The problem is, that D does not work if you use non-private imports all
 the time. Suddenly there are conflicts.
  A public import make the imported module part of this modules  
 interface.
 This can (and should) be made public explicitely.

Totally agree. As for the consistency issue, it was said private imports by default where worth the small inconsistency (of everything else being public). Actually I disagree with that at the premise level: I don't think it would be an inconsistency at all. Imports are not members of the module, as they do not even define a new entity. They are not a "part of" the module, they are more like a characteristic of it. Further indication is that there is no "package import". And even "public import", would it be of any significant use? (Of course one could think of imports as the definition of a set of aliases, but really, I would think that's an unadequate and contrived conceptualization)

Good point. Perhaps the current private import should be the default, and to achieve the current public import, something else could be used, such as "static import" ? Since the majority of imports are private, and even some public ones should have been private, I don't think this change would be difficult. The most common case would then be: * Default, logical choice; * Easier to type; * Better looking code;

I'm not so sure that makes sense :) Yes, there's a long standing problem with symbol/namespace collisions and it would be great to resolve that. Bruno suggests that imports are nothing more than a "characteristic" of a module ~ that makes sense, but then couldn't one also think of a class contained therein as a characteristic too? Especially a class that is intended /not/ to be exposed outside of the module (which we apparently cannot hide via package or private; right?). In order to make D easy to learn and use, surely consistency in usage should be a priority? D kinda has that right now in this particular area, in that everything is public by default. It would also be fine, IMO, if everything were private by default :) Either way, the symbol/namespace collision thing has been thorny for a long time. I'm not so sure that would even be resolved properly by making imports private anyway -- it may mask the problem a little. - Kris
Apr 13 2006
parent reply "Derek Parnell" <derek psych.ward> writes:
On Fri, 14 Apr 2006 03:37:14 +1000, kris <foo bar.com> wrote:

 In order to make D easy to learn and use, surely consistency in usage  
 should be a priority? D kinda has that right now in this particular  
 area, in that everything is public by default. It would also be fine,  
 IMO, if everything were private by default :)

How many cars have rubber steering wheels? After all, the other wheels are made of rubber and we do worship consistency? -- Derek Parnell Melbourne, Australia
Apr 13 2006
parent reply Sean Kelly <sean f4.ca> writes:
Derek Parnell wrote:
 On Fri, 14 Apr 2006 03:37:14 +1000, kris <foo bar.com> wrote:
 
 In order to make D easy to learn and use, surely consistency in usage 
 should be a priority? D kinda has that right now in this particular 
 area, in that everything is public by default. It would also be fine, 
 IMO, if everything were private by default :)

How many cars have rubber steering wheels? After all, the other wheels are made of rubber and we do worship consistency?

Oh come on, that's a false analogy. Sean
Apr 13 2006
next sibling parent "Chris Miller" <chris dprogramming.com> writes:
On Thu, 13 Apr 2006 22:06:08 -0400, Sean Kelly <sean f4.ca> wrote:

 Derek Parnell wrote:
 On Fri, 14 Apr 2006 03:37:14 +1000, kris <foo bar.com> wrote:

 In order to make D easy to learn and use, surely consistency in usage  
 should be a priority? D kinda has that right now in this particular  
 area, in that everything is public by default. It would also be fine,  
 IMO, if everything were private by default :)

are made of rubber and we do worship consistency?

Oh come on, that's a false analogy.

How about an airbag made of buckles? Seriously, objects in this mirror are closer than that one? [safely ignore this]
Apr 13 2006
prev sibling parent reply "Derek Parnell" <derek psych.ward> writes:
On Fri, 14 Apr 2006 12:06:08 +1000, Sean Kelly <sean f4.ca> wrote:

 Derek Parnell wrote:
 On Fri, 14 Apr 2006 03:37:14 +1000, kris <foo bar.com> wrote:

 In order to make D easy to learn and use, surely consistency in usage  
 should be a priority? D kinda has that right now in this particular  
 area, in that everything is public by default. It would also be fine,  
 IMO, if everything were private by default :)

are made of rubber and we do worship consistency?

Oh come on, that's a false analogy.

Sorry. "the heat of the moment" and all that stuff ... don't know what came over me. I'm just not convinced yet that "consistency" is the highest design priority. To me, "usability" is more important even if that means that two things are not 'consistent'. -- Derek Parnell Melbourne, Australia
Apr 13 2006
next sibling parent Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Derek Parnell wrote:
 On Fri, 14 Apr 2006 12:06:08 +1000, Sean Kelly <sean f4.ca> wrote:
 
 Derek Parnell wrote:
 On Fri, 14 Apr 2006 03:37:14 +1000, kris <foo bar.com> wrote:

 In order to make D easy to learn and use, surely consistency in 
 usage should be a priority? D kinda has that right now in this 
 particular area, in that everything is public by default. It would 
 also be fine, IMO, if everything were private by default :)

wheels are made of rubber and we do worship consistency?

Oh come on, that's a false analogy.

Sorry. "the heat of the moment" and all that stuff ... don't know what came over me. I'm just not convinced yet that "consistency" is the highest design priority. To me, "usability" is more important even if that means that two things are not 'consistent'. --Derek Parnell Melbourne, Australia

I would like a language such as D to strive for the utmost consistency and orthogonality but also for "practicality" and "usability" (two qualities often hard to conciliate). So for me too it's not the prime, all-important goal, otherwise I'd be using LISP :P -- Bruno Medeiros - CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Apr 14 2006
prev sibling next sibling parent Sean Kelly <sean f4.ca> writes:
Derek Parnell wrote:
 On Fri, 14 Apr 2006 12:06:08 +1000, Sean Kelly <sean f4.ca> wrote:
 
 Derek Parnell wrote:
 On Fri, 14 Apr 2006 03:37:14 +1000, kris <foo bar.com> wrote:

 In order to make D easy to learn and use, surely consistency in 
 usage should be a priority? D kinda has that right now in this 
 particular area, in that everything is public by default. It would 
 also be fine, IMO, if everything were private by default :)

wheels are made of rubber and we do worship consistency?

Oh come on, that's a false analogy.

Sorry. "the heat of the moment" and all that stuff ... don't know what came over me. I'm just not convinced yet that "consistency" is the highest design priority. To me, "usability" is more important even if that means that two things are not 'consistent'.

I use the term 'consistency' a lot, but a more appropriate term may be 'predictability'. Basically, I'm willing to bend on consistency so long as the result is still behavior that a novice would consider predictable. That said, I prefer consistency here as the import metaphor isn't limited to just imports--it includes mixins as well. As an aside, it would be really nice if there were a way to expose a single symbol from a privately imported module. 'alias' doesn't work because it will result in multiply defined symbol errors if both modules are imported by a third module. This has come up a lot writing Posix headers because the bulk of them are required to expose one or two symbols from another header such as sys/types. This can be accomplished with preprocessor language in C, but there's no way around publicly importing the entire parent module in D. Sean
Apr 14 2006
prev sibling parent reply kris <foo bar.com> writes:
Derek Parnell wrote:
 On Fri, 14 Apr 2006 12:06:08 +1000, Sean Kelly <sean f4.ca> wrote:
 
 Derek Parnell wrote:

 On Fri, 14 Apr 2006 03:37:14 +1000, kris <foo bar.com> wrote:

 In order to make D easy to learn and use, surely consistency in 
 usage  should be a priority? D kinda has that right now in this 
 particular  area, in that everything is public by default. It would 
 also be fine,  IMO, if everything were private by default :)

How many cars have rubber steering wheels? After all, the other wheels are made of rubber and we do worship consistency?

Oh come on, that's a false analogy.

Sorry. "the heat of the moment" and all that stuff ... don't know what came over me. I'm just not convinced yet that "consistency" is the highest design priority. To me, "usability" is more important even if that means that two things are not 'consistent'.

I'm a big fan of the "Principal Of Least Surprise", where 'consistency' is often a prime factor. You're right, of course, that the latter does not always produce the former, even though it typically does. Further, I suspect that most "veteran" engineers would agree that "all private by default" produces the least surprises over time. Symbolic encapsulation, as a /default/, would probably be a good thing. How hard is it to type the word "public" when necessary? Either way, let's not lose sight of the rather obvious question-mark: would private imports resolve the symbol/namespace collisions? In my humble experience with D, it does not.
Apr 14 2006
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
kris wrote:

 Either way, let's not lose sight of the rather obvious question-mark:
 would private imports resolve the symbol/namespace collisions? In my
 humble experience with D, it does not.

But then we could at least label it as a bug with certainty.
Apr 14 2006
parent kris <foo bar.com> writes:
Lars Ivar Igesund wrote:
 kris wrote:
 
 
Either way, let's not lose sight of the rather obvious question-mark:
would private imports resolve the symbol/namespace collisions? In my
humble experience with D, it does not.

But then we could at least label it as a bug with certainty.

heheh :) You can do that today by making most imports explicitly private. Mango is pretty careful about this, where only those things required by ctors are exposed via public or package. Everything else is private. History indicates that things labeled as "bugs" within this realm are simply renamed as "features" :)
Apr 14 2006
prev sibling parent Don Clugston <dac nospam.com.au> writes:
Bruno Medeiros wrote:
 Frank Benoit wrote:
 There was a posting of Tyro
 http://www.digitalmars.com/d/archives/digitalmars/D/11081.html

 Most ppl seconded that.

 The problem is, that D does not work if you use non-private imports all
 the time. Suddenly there are conflicts.

 A public import make the imported module part of this modules interface.
 This can (and should) be made public explicitely.

Totally agree. As for the consistency issue, it was said private imports by default where worth the small inconsistency (of everything else being public). Actually I disagree with that at the premise level: I don't think it would be an inconsistency at all. Imports are not members of the module, as they do not even define a new entity. They are not a "part of" the module, they are more like a characteristic of it. Further indication is that there is no "package import". And even "public import", would it be of any significant use?

Definitely. Think of the windows API, where windows.d imports dozens of modules. It would be very inconvenient to have to list every module you were using (and you'd have to know where they are). A public import of module dog into module bird adds the public members of 'dog' to the interface of 'bird'. It's very rare that this is what you want, but it certainly occurs. I think one way in which it's fundamentally different to classes is that it's natural to have a 'web' of dependencies between modules. It's plausible that importing a single file could clandestinely import a hundred others.
 (Of course one could think of imports as the definition of a set of 
 aliases, but really, I would think that's an unadequate and contrived 
 conceptualization)

Apr 13 2006
prev sibling parent David Medlock <noone nowhere.com> writes:
Frank Benoit wrote:
 There was a posting of Tyro
 http://www.digitalmars.com/d/archives/digitalmars/D/11081.html
 
 Most ppl seconded that.
 
 The problem is, that D does not work if you use non-private imports all
 the time. Suddenly there are conflicts.
 
 A public import make the imported module part of this modules interface.
 This can (and should) be made public explicitely.
 

Possibly pertinent discussion on artima: http://www.artima.com/forums/flat.jsp?forum=106&thread=147355 -DavidM
Apr 13 2006