Thread overview | ||||||
---|---|---|---|---|---|---|
|
July 27, 2005 Whats wrong with this?? | ||||
---|---|---|---|---|
| ||||
///// 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. |
July 27, 2005 Re: Whats wrong with this?? | ||||
---|---|---|---|---|
| ||||
Posted in reply to BCS | "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. |
July 27, 2005 Re: Whats wrong with this?? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ben Hinkle | 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. |
July 28, 2005 Re: Whats wrong with this?? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dave | 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. |
Copyright © 1999-2021 by the D Language Foundation