• BCS (9/9) Jul 22 2005 Given the file structure.
• Ben Hinkle (9/21) Jul 22 2005 yes
• Andrew Fedoniouk (28/42) Jul 22 2005 Not yet. Still a bug I beleive.
• BCS (8/22) Jul 23 2005 [snip]
• Ben Hinkle (9/39) Jul 23 2005 I haven't actually tried all the variations on specifying the access

BCS <BCS_member pathlink.com> writes:

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.

"Ben Hinkle" <ben.hinkle gmail.com> writes:

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

"Andrew Fedoniouk" <news terrainformatica.com> writes:

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

BCS <BCS_member pathlink.com> writes:

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:




or as in 



or as "global" stuff?

"Ben Hinkle" <ben.hinkle gmail.com> writes:

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




 or as in



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