Given the file structure.

~/base.d
~/sub/test.d

Can a file ~/sub/test.d import the file ~/base.d ?

If so, would test.d NOT be able to access package attribute items in base.d?

I'm hopeing this is the case because it would make life easy for me. If not I’ll have to look for something else.

Whatever that case, this part of the reference could use some work as it is not clear.

"BCS" <BCS_member@pathlink.com> wrote in message news:dbrrl6$1qnr$1@digitaldaemon.com...
> Given the file structure.
>
> ~/base.d
> ~/sub/test.d
>
> Can a file ~/sub/test.d import the file ~/base.d ?

yes

> If so, would test.d NOT be able to access package attribute items in base.d?

correct except for some bugs - like it seems top-level access attributes are ignored and struct attributes are ignored. But fields and methods of classes obey package as you describe.

> I'm hopeing this is the case because it would make life easy for me. If
> not I'll
> have to look for something else.
>
> Whatever that case, this part of the reference could use some work as it
> is not
> clear.

I imagine if you have more specific tips it would be appreciated. Also one can add comments about the doc using the doc wiki links at the bottom of the web page.

"Ben Hinkle" <ben.hinkle@gmail.com> wrote in message news:dbs4jn$20kr$1@digitaldaemon.com...
>
> "BCS" <BCS_member@pathlink.com> wrote in message news:dbrrl6$1qnr$1@digitaldaemon.com...
>> Given the file structure.
>>
>> ~/base.d
>> ~/sub/test.d
>>
>> Can a file ~/sub/test.d import the file ~/base.d ?
>
> yes
>
>> If so, would test.d NOT be able to access package attribute items in base.d?
>
> correct except for some bugs - like it seems top-level access attributes are ignored and struct attributes are ignored.


> But fields and methods of classes obey package as you describe.

Not yet. Still a bug I beleive.

Try to compile following: /test.d and /sub/test1.d
-------------------------------
module test;

import std.stdio;
import sub.test1;

class Bar
{
  package static void bar() { printf("s"); }
  package void foo() { printf("m"); }
}

int main()
{
 Bar t = new Bar;
 sub.test1.zoo(t);
 return 0;
}

-----------------------------
module sub.test1;

import test;

void zoo(test.Bar t)
{
  test.Bar.bar(); // OK.
  t.foo(); // ERROR: method foo() is not accessible
}
-------------------------------

In article <dbs4jn$20kr$1@digitaldaemon.com>, Ben Hinkle says...
>
>
>"BCS" <BCS_member@pathlink.com> wrote in message news:dbrrl6$1qnr$1@digitaldaemon.com...
>> Given the file structure.
>>
>> ~/base.d
>> ~/sub/test.d
>>
>> Can a file ~/sub/test.d import the file ~/base.d ?
>
>yes
>
>> If so, would test.d NOT be able to access package attribute items in base.d?
>
>correct except for some bugs - like it seems top-level access attributes are ignored and struct attributes are ignored. But fields and methods of classes obey package as you describe.
>
[snip]

Top-level as in:

#    package:
#    int i;

or as in

#    package int i;

or as "global" stuff?

"BCS" <BCS_member@pathlink.com> wrote in message news:dbtsks$ksd$1@digitaldaemon.com...
> In article <dbs4jn$20kr$1@digitaldaemon.com>, Ben Hinkle says...
>>
>>
>>"BCS" <BCS_member@pathlink.com> wrote in message news:dbrrl6$1qnr$1@digitaldaemon.com...
>>> Given the file structure.
>>>
>>> ~/base.d
>>> ~/sub/test.d
>>>
>>> Can a file ~/sub/test.d import the file ~/base.d ?
>>
>>yes
>>
>>> If so, would test.d NOT be able to access package attribute items in base.d?
>>
>>correct except for some bugs - like it seems top-level access attributes
>>are
>>ignored and struct attributes are ignored. But fields and methods of
>>classes
>>obey package as you describe.
>>
> [snip]
>
> Top-level as in:
>
> #    package:
> #    int i;
>
> or as in
>
> #    package int i;
>
> or as "global" stuff?

I haven't actually tried all the variations on specifying the access attribute. I just tried the second one you have but I would assume all symbols defined at the module scope would have the same behavior. The access attributes are correctly handled by the implicit name lookup algorithm but not when you explicitly specify the package and module name. So if foo is a module with a private int i then bar importing foo can't access "i" but it can access "foo.i".