www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Are public/private imports implemented?

reply Ary Borenszweig <ary esperanto.org.ar> writes:
Again, testing some Descent semantic code, I was getting errors on 
undefined functions.

---
module one;

import two;

void foo() {
	char[] srcfilename = std.path.join("one", "two");
}
---

---
module two;

import std.path; // same with "private import std.path;"
---

I was getting an error on "std.path.join", because since the import on 
module two is private, join is not visible. But DMD seems to compile it 
without problems. What's the truth about imports?
Jan 21 2008
parent reply "Tyro[a.c.edwards]" <no spam.com> writes:
Ary Borenszweig ????????:

 Again, testing some Descent semantic code, I was getting errors on 
 undefined functions.
 
 ---
 module one;
 
 import two;
 
 void foo() {
     char[] srcfilename = std.path.join("one", "two");
 }
 ---
 
 ---
 module two;
 
 import std.path; // same with "private import std.path;"
 ---
 
 I was getting an error on "std.path.join", because since the import on 
 module two is private, join is not visible. But DMD seems to compile it 
 without problems. What's the truth about imports?


module imports are private by default. This means that since you 
"privately" imported std.path into module two, then the entire content 
of the std.path module becomes visible to module two, and module two 
alone. As a result std.path is not defined in module one. In order for 
it to be defined, you would also need to import std.path in module one 
or do "public import std.path;" in module two.

Andrew
Jan 21 2008
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Tyro[a.c.edwards] wrote:

 Ary Borenszweig ????????:

 Again, testing some Descent semantic code, I was getting errors on 
 undefined functions.

 ---
 module one;

 import two;

 void foo() {
     char[] srcfilename = std.path.join("one", "two");
 }
 ---

 ---
 module two;

 import std.path; // same with "private import std.path;"
 ---

 I was getting an error on "std.path.join", because since the import on 
 module two is private, join is not visible. But DMD seems to compile 
 it without problems. What's the truth about imports?


 
 module imports are private by default. This means that since you 
 "privately" imported std.path into module two, then the entire content 
 of the std.path module becomes visible to module two, and module two 
 alone. As a result std.path is not defined in module one. In order for 
 it to be defined, you would also need to import std.path in module one 
 or do "public import std.path;" in module two.


The truth seems to be more that fully qualified names are always made 
public.
http://d.puremagic.com/issues/show_bug.cgi?id=314.

--bb
Jan 21 2008
parent reply "Tyro[a.c.edwards]" <no spam.com> writes:
Bill Baxter さんは書きました:

 Tyro[a.c.edwards] wrote:

 Ary Borenszweig ????????:

 Again, testing some Descent semantic code, I was getting errors on 
 undefined functions.

 ---
 module one;

 import two;

 void foo() {
     char[] srcfilename = std.path.join("one", "two");
 }
 ---

 ---
 module two;

 import std.path; // same with "private import std.path;"
 ---

 I was getting an error on "std.path.join", because since the import 
 on module two is private, join is not visible. But DMD seems to 
 compile it without problems. What's the truth about imports?


 module imports are private by default. This means that since you 
 "privately" imported std.path into module two, then the entire content 
 of the std.path module becomes visible to module two, and module two 
 alone. As a result std.path is not defined in module one. In order for 
 it to be defined, you would also need to import std.path in module one 
 or do "public import std.path;" in module two.


 
 The truth seems to be more that fully qualified names are always made 
 public.
 http://d.puremagic.com/issues/show_bug.cgi?id=314.
 
 --bb


I thought I ran across that bug a few weeks back when I bought and 
started reading "Learn to Tango with D" but somehow managed to convince 
myself that it didn't exist.

Thanks bb.

Andrew
Jan 21 2008
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Tyro[a.c.edwards] wrote:

 Bill Baxter さんは書きました:

 Tyro[a.c.edwards] wrote:

 Ary Borenszweig ????????:

 Again, testing some Descent semantic code, I was getting errors on 
 undefined functions.

 ---
 module one;

 import two;

 void foo() {
     char[] srcfilename = std.path.join("one", "two");
 }
 ---

 ---
 module two;

 import std.path; // same with "private import std.path;"
 ---

 I was getting an error on "std.path.join", because since the import 
 on module two is private, join is not visible. But DMD seems to 
 compile it without problems. What's the truth about imports?


 module imports are private by default. This means that since you 
 "privately" imported std.path into module two, then the entire 
 content of the std.path module becomes visible to module two, and 
 module two alone. As a result std.path is not defined in module one. 
 In order for it to be defined, you would also need to import std.path 
 in module one or do "public import std.path;" in module two.


 The truth seems to be more that fully qualified names are always made 
 public.
 http://d.puremagic.com/issues/show_bug.cgi?id=314.

 --bb


 
 I thought I ran across that bug a few weeks back when I bought and 
 started reading "Learn to Tango with D" but somehow managed to convince 
 myself that it didn't exist.
 


It's going to bite me hard if it ever gets fixed.  For imports I'm not 
using extensively in a module I tend to use fully qualified names and 
take a "shoot first; ask questions later" approach.  So for instance I'm 
sure I have *lots* of std.string.format()'s in modules that never 
imported std.string which just happen to work because some module 
somewhere that I imported does.

--bb
Jan 21 2008
parent Ary Borenszweig <ary esperanto.org.ar> writes:
Bill Baxter escribió:

 It's going to bite me hard if it ever gets fixed.  For imports I'm not 
 using extensively in a module I tend to use fully qualified names and 
 take a "shoot first; ask questions later" approach.  So for instance I'm 
 sure I have *lots* of std.string.format()'s in modules that never 
 imported std.string which just happen to work because some module 
 somewhere that I imported does.
 
 --bb


Thanks for your answers.

Phobos is going to be bitten hard if it gets fixed, but the fix is 
pretty easy: just add import statements. :-)

For now, I'll make Descent have that bug too, so it behaves exactly like 
DMD (although it's harder for me to implement that incorrectly :-P).
Jan 21 2008
prev sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Tyro[a.c.edwards]" <no spam.com> wrote in message 
news:fn353h$2ni1$3 digitalmars.com...

 I thought I ran across that bug a few weeks back when I bought and started 
 reading "Learn to Tango with D" but somehow managed to convince myself 
 that it didn't exist.


I kind of wonder if W's done the same.
Jan 21 2008
parent reply "Tyro[a.c.edwards]" <no spam.com> writes:
Jarrett Billingsley $B$5$s$O=q$-$^$7$?(B:

 "Tyro[a.c.edwards]" <no spam.com> wrote in message 
 news:fn353h$2ni1$3 digitalmars.com...

 I thought I ran across that bug a few weeks back when I bought and started 
 reading "Learn to Tango with D" but somehow managed to convince myself 
 that it didn't exist.


 
 I kind of wonder if W's done the same. 
 
 


No! I don't think so. Just hasn't bubbled up to the top of the list as
yet. Got to admit that there are a lot of processes competing for WPT
(Walter Processing Time). Probably just need to modify the process
scheduler a bit to take this into consideration and downgrade the
priority of a few of those "greedy" processes (const comes to mind here)
so that those oft ignored once get their chance to surface.
Jan 21 2008
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Tyro[a.c.edwards]" <no spam.com> wrote in message 
news:fn3l7g$17ef$1 digitalmars.com...


 No! I don't think so. Just hasn't bubbled up to the top of the list as
 yet. Got to admit that there are a lot of processes competing for WPT
 (Walter Processing Time). Probably just need to modify the process
 scheduler a bit to take this into consideration and downgrade the
 priority of a few of those "greedy" processes (const comes to mind here)
 so that those oft ignored once get their chance to surface.


I was thinking about this; not only is const's priority much higher than 
anything else, Walter seems to follow a SJF (shortest job first) process 
schedule.  Unfortunately this means given a steady stream of small, 
easier-to-fix issues, the older, larger ones tend never to get fixed.

It's kind of sad, really.
Jan 21 2008