And what will we do about package?

[Denis Koroskin]

On Fri, 20 Nov 2009 19:52:09 +0300, Don <nospam at nospam.com> 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.

I never felt a need for "package" module attribute. But at class  
protection level, package implying final is ... ouch!