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?

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

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

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

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

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

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

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.

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