View mode: basic / threaded / horizontal-split · Log in · Help
November 20, 2009
And what will we do about package?
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.
November 20, 2009
Re: And what will we do about package?
On Fri, 20 Nov 2009 19:52:09 +0300, Don <nospam@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!
November 20, 2009
Re: And what will we do about package?
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.
November 21, 2009
Re: And what will we do about package?
On Fri, 20 Nov 2009 18:52:09 +0200, Don <nospam@nospam.com> wrote:

> module first.second.third.fourth;
>  which package is this module part of?
> Is it 'third', 'second.third', or 'first.second.third'?

Perhaps you meant: 'first', 'first.second', or 'first.second.third'?

The case you mention presents an immediate ambiguity, but it is clarified  
by the module declaration or on the first import. If 'first.second.foo'  
imports 'first.second.third.bar' by 'import third.bar', and  
'first.second.third.bar' has a module declaration or is imported from  
somewhere else using a different package "path", the compiler will  
generate an error ("Error: module X is in multiple packages Y")

-- 
Best regards,
 Vladimir                          mailto:thecybershadow@gmail.com
November 21, 2009
Re: And what will we do about package?
Vladimir Panteleev wrote:
> On Fri, 20 Nov 2009 18:52:09 +0200, Don <nospam@nospam.com> wrote:
> 
>> module first.second.third.fourth;
>>  which package is this module part of?
>> Is it 'third', 'second.third', or 'first.second.third'?
> 
> Perhaps you meant: 'first', 'first.second', or 'first.second.third'?


> 
> The case you mention presents an immediate ambiguity, but it is 
> clarified by the module declaration or on the first import. If 
> 'first.second.foo' imports 'first.second.third.bar' by 'import 
> third.bar', and 'first.second.third.bar' has a module declaration or is 
> imported from somewhere else using a different package "path", the 
> compiler will generate an error ("Error: module X is in multiple 
> packages Y")

How do you define module fourth so that its 'package' functions are 
accesssable only to modules in first.second.* and not in first.* ?
November 21, 2009
Re: And what will we do about package?
Don wrote:
> Vladimir Panteleev wrote:
>> On Fri, 20 Nov 2009 18:52:09 +0200, Don <nospam@nospam.com> wrote:
>>
>>> module first.second.third.fourth;
>>>  which package is this module part of?
>>> Is it 'third', 'second.third', or 'first.second.third'?
>>
>> Perhaps you meant: 'first', 'first.second', or 'first.second.third'?
> 
> 
>>
>> The case you mention presents an immediate ambiguity, but it is 
>> clarified by the module declaration or on the first import. If 
>> 'first.second.foo' imports 'first.second.third.bar' by 'import 
>> third.bar', and 'first.second.third.bar' has a module declaration or 
>> is imported from somewhere else using a different package "path", the 
>> compiler will generate an error ("Error: module X is in multiple 
>> packages Y")
> 
> How do you define module fourth so that its 'package' functions are 
> accesssable only to modules in first.second.* and not in first.* ?
> 

You don't. The package in this case should be first.second.third and 
that's that. That's how it works in Java and is sometimes quite useful.
November 21, 2009
Re: And what will we do about package?
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'?
> 
...

Assuming you meant first, first.second and first.second.third, I'd say the 
most sensible choice is first.second.third (I actually assumed it works this 
way already). 

Why? Currently the most coarse level of granularity (excluding package) that 
has any meaning in D is the module level. If you want 'friend' access one 
step beyond that it only makes sense to choose the modules that map to the 
same directory. I'd like to think that is more than enough exposure for 
anyone.

Anything beyond that seems way too promiscuous to me, like a poor substitute 
for C++'s friend.
Top | Discussion index | About this forum | D home