And what will we do about package?

[Yigal Chripun]

Don wrote:
> To quote bugzilla 143: 'package' does not work at all
> 
> But even if worked as advertised, it'd still be broken.
> 
> Although it's a really useful concept that works great in Java, the 
> existing 'package' doesn't fit with D's directory-based module system.
> As I see it, the problem is that, given:
> 
> module first.second.third.fourth;
> 
> which package is this module part of?
> Is it 'third', 'second.third', or 'first.second.third'?
> 
> I think that _all_ of those can be reasonable project designs; but the 
> compiler has no way of working out which is intended.
> The behaviour currently described in the spec, that 'fourth' can use 
> functions defined in 'first', is a particularly odd choice. If they were 
> structs, the behaviour would be the exact opposite:
> 
> struct first {
>    struct second {
>       struct third {
>            int fourth;
>       }
>    }
> }
> then first could access fourth, but fourth couldn't reach second. I 
> think that's _generally_ the most sensible for modules, as well.
> 
> I think there are two possibilities:
> (1) We work out some decent semantics for 'package'; OR
> (2) We decide there isn't time, and defer it to D3.
> 
> Maybe the solution is a simple as adding a 'package' field to the module 
> declaration. (eg,
> module first.second.third.fourth package first.second;
> )
> But I fear that a major change to the module system might be required, 
> which wouldn't be viable at this late stage.
> 
> Option (2) is possible because 'package' has never actually worked. It 
> seems to be just a synonym for 'public' at present. Clearly, we can 
> survive without it, no matter how desirable it is.

Well put.

I think we can just drop "package" and adopt a similar model to that of 
Go with D modules. it looks simple and flexible. especially the ability 
to have a Go package span several files.