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 :)


  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.


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 :)


  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'.

-- 
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 :)


  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'.
 
 --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 :)


  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 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