On Monday 08 August 2011 08:55:22 Jacob Carlborg wrote: > On 2011-08-07 23:18, Jonathan M Davis wrote: > > On Sunday 07 August 2011 18:58:53 Stijn Herreman wrote: > >> module main; > >> > >> import std.stdio; > >> import my_module; > >> > >> int main() > >> { > >> > >> my_method(); > >> return 0; > >> > >> } > >> > >> > >> module my_module; > >> > >> import std.stdio; > >> > >> package void my_method() > >> { > >> > >> writeln("Hello D-World!"); > >> > >> } > >> > >> > >> Error: function my_module.my_method is not accessible from main > > > > Hmmm. My guess would be that either it's a bug or that from D's > > perspective, neither of your modules are in a package. They have no > > package in front of their names; they're at the base level of the > > hierarchy. And that might mean that they don't have a package, so they > > don't share a package. But I don't know. > > > > Personally, I don't see much point in using the package specifier when > > you're not actually using a package hierarchy (you're just making it so > > that everything but stuff which actually uses a hierarchy can use the > > function - it would be a really weird distinction to make). So, it > > wouldn't entirely surprise me if this is completely by design. It might > > be a bug though. > > > > - Jonathan M Davis > > Or because neither of the modules are in package they are perhaps in an > implicit global package making "package" in this case behave as public.
Except that I don't think that sub-packages have access to the package functions in their parent packages, and if that's true, then it's not the same as public. However, if they _do_ have access to their parent packages' package functions, then it _is_ the same as public. I don't think that they do though. But of course, I could be wrong about that. - Jonathan M Davis