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

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

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.

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.