• BCS (27/27) Jul 26 2005 ///// file /a.d
• Ben Hinkle (7/35) Jul 27 2005 Looks like package access only works with "non-trivial" packages (ie the...
• Dave (6/51) Jul 27 2005 I think that is the intent - it has worked that way for several versions...
• BCS (8/23) Jul 27 2005 Thank you, I'll try that.

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.

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

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.

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.