And what will we do about package?

Don nospam at nospam.com
Fri Nov 20 08:52:09 PST 2009


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.



More information about the Digitalmars-d mailing list