www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Whats wrong with this??

reply BCS <BCS_member pathlink.com> writes:
///// file /a.d

class Item
{
package void F(uint fi){f=fi;}

private:
uint f;
}

/////file /b.d

import a;

class A
{
Item New()
{
return null;
}
}

private A		array[];


int B()
{
Item i = new Item; 
i.F(cast(uint)0);		// line 17
return 0;
}

// compile output:
//b.d(17): class a.Item member F is not accessible

If F(uint fi) is public, it works. They are all in the same directory by them
selves.
Jul 26 2005
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"BCS" <BCS_member pathlink.com> wrote in message 
news:dc72eo$1v0m$1 digitaldaemon.com...
 ///// file /a.d

 class Item
 {
 package void F(uint fi){f=fi;}

 private:
 uint f;
 }

 /////file /b.d

 import a;

 class A
 {
 Item New()
 {
 return null;
 }
 }

 private A array[];


 int B()
 {
 Item i = new Item;
 i.F(cast(uint)0); // line 17
 return 0;
 }

 // compile output:
 //b.d(17): class a.Item member F is not accessible

 If F(uint fi) is public, it works. They are all in the same directory by 
 them
 selves.

Looks like package access only works with "non-trivial" packages (ie the lack of any package is not considered a package). Meaning if you put "module dir.a;" and "module dir.b;" statements in a.d and b.d then it works since the modules are in package "dir". I don't know if this is a bug that a package is needed in order to have package access.
Jul 27 2005
parent reply Dave <Dave_member pathlink.com> writes:
In article <dc8rv8$lat$1 digitaldaemon.com>, Ben Hinkle says...
"BCS" <BCS_member pathlink.com> wrote in message 
news:dc72eo$1v0m$1 digitaldaemon.com...
 ///// file /a.d

 class Item
 {
 package void F(uint fi){f=fi;}

 private:
 uint f;
 }

 /////file /b.d

 import a;

 class A
 {
 Item New()
 {
 return null;
 }
 }

 private A array[];


 int B()
 {
 Item i = new Item;
 i.F(cast(uint)0); // line 17
 return 0;
 }

 // compile output:
 //b.d(17): class a.Item member F is not accessible

 If F(uint fi) is public, it works. They are all in the same directory by 
 them
 selves.

Looks like package access only works with "non-trivial" packages (ie the lack of any package is not considered a package). Meaning if you put "module dir.a;" and "module dir.b;" statements in a.d and b.d then it works since the modules are in package "dir". I don't know if this is a bug that a package is needed in order to have package access.

I think that is the intent - it has worked that way for several versions. By 'worked that way' I mean that class items with the 'package' attribute are not accessible unless the imported code is explicitly tagged as belonging to the same package. So far, I think this applies to just class members, not struct or 'top level' vars. or funcs.
Jul 27 2005
parent BCS <BCS_member pathlink.com> writes:
Thank you, I'll try that.

This looks like the same problem I posted about a while ago, ‘what exactly IS a
package??' the reference doesn't say vary much on this.

One specific questions I'd like to see addressed in the reference:
Does package limit to only code in the same directory, sub directories, parent
directories, or some combination?


In article <dc91ji$po4$1 digitaldaemon.com>, Dave says...
In article <dc8rv8$lat$1 digitaldaemon.com>, Ben Hinkle says...


[snip]
Looks like package access only works with "non-trivial" packages (ie the 
lack of any package is not considered a package). Meaning if you put "module 
dir.a;" and "module dir.b;" statements in a.d and b.d then it works since 
the modules are in package "dir". I don't know if this is a bug that a 
package is needed in order to have package access. 

I think that is the intent - it has worked that way for several versions. By 'worked that way' I mean that class items with the 'package' attribute are not accessible unless the imported code is explicitly tagged as belonging to the same package. So far, I think this applies to just class members, not struct or 'top level' vars. or funcs.

Jul 27 2005