www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - How does "package" work?

reply 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.
Jul 22 2005
parent reply "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.
Jul 22 2005
next sibling parent "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 } -------------------------------
Jul 22 2005
prev sibling parent reply 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.

Top-level as in: # package: # int i; or as in # package int i; or as "global" stuff?
Jul 23 2005
parent "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.

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".
Jul 23 2005