Walter wrote:

> There are two ways to provide package level 'friend' access:
> 
> 1) simply allow private members to be accessed from other modules in the same package
> 
> 2) have another attribute: 'package'.
> 
> I prefer (1) to avoid a proliferation of keywords and complexity with
> little added value.

1 is nice except it is a pity to lose the ability to have "really private"
declarations. For example would this affect optimizations when the compiler
has to assume a given symbol can be accessed from outside the file it is
currently compiling?
One way to help here is to take the public/private to the module
declaration. If the "private" keyword is before the "module" keyword then
all the private declaration in the module are truly private and public
declarations are "package". Otherwise by default the private declarations
are "package" as you propose and public is the same as it is now: public
everywhere. For example

file pkg/foo.d:
private module pkg.foo;
private int a;  // only visible in foo.d
int a2;         // visible in foo.d and bar.d but not outside pkg

file pkg/bar.d:
module pkg.bar;
private int b;  // visible in bar.d and foo.d but not outside pkg
int b2;         // visible anywhere

On Wed, 02 Jun 2004 09:40:57 +1200, Regan Heath wrote:

> On Tue, 01 Jun 2004 17:26:11 -0400, DemmeGod <me@demmegod.com> wrote:
>> On Wed, 02 Jun 2004 09:08:49 +1200, Regan Heath wrote:
>>
>>> On Tue, 1 Jun 2004 13:41:26 -0700, Walter <newshound@digitalmars.com> wrote:
>>>
>>>> There are two ways to provide package level 'friend' access:
>>>>
>>>> 1) simply allow private members to be accessed from other modules in
>>>> the
>>>> same package
>>>
>>> What defines a 'package' in this case?
>> The folder... which is everything before the module name. eg: in the module a.b.c, a.b is the package.
> 
> So 'std' in phobos is the package, and they'd all get 'friend' access to each other?
> 
>>>> 2) have another attribute: 'package'.
>>>>
>>>> I prefer (1) to avoid a proliferation of keywords and complexity with
>>>> little added value.
> 
> Wouldn't (1) cause a 'proliferation' of directories with 1 file in them?
> Or.. (as seems to be the case at the moment) are the directories
> themselves un-necessary?

Yes, and yes, which is why I support (2)

On Tue, 01 Jun 2004 21:42:40 +0000, Arcane Jill wrote:

> In article <opr8xo0znz5a2sq9@digitalmars.com>, Regan Heath says...
>>
>>What defines a 'package' in this case?
> 
> I'm not sure I know the /official/ answer, but I know how I'd like it to be defined.
> 
> I'd like package-visibility to mean visible to any d source file in the same directory, in the parent directory, the grandparent directory, and so on recursively, and to no others.

In this scenario, wouldn't any class not specifying a module (but in the same source tree) be allowed access to the package-visible level stuff? If there's to be any recursive access, I would prefer quite the opposite, where the children and grand-children have access.  The children of a package strike me as more likely to be interacting or extending (not subclassing) the package's modules.

Having package-visibility only in the immediate package is also fine for me, however.

> I'd also like for you to make it possible for a module and a directory to have the same name. In my big integer project, I have the main file, the one I expect people to most commonly import, in "etc.bigint". It would have been really nice to have been able to have had the supporting files being "etc.bigint.xxxxx" (instead of, as I was more or less forced to do, "etc.bigint_files.xxxxx").

I put a bug report about this in to the bugs NG.  This change would be appriciated.

> 
> In this case, package access should mean that:
> 
> *) etc.bigint.xxxxx has access to etc.bigint.yyyyy's package-access variables. *) etc.bigint has access to etc.bigint.xxxxx's package-access variables. *) etc.bigint.xxxxx does NOT have access to etc.bigint's package-access variables.
> 
> That's my wish-list.
> Jill

"Walter" <newshound@digitalmars.com> wrote in message news:c9ipvn$28dc$1@digitaldaemon.com...
> There are two ways to provide package level 'friend' access:
>
> 1) simply allow private members to be accessed from other modules in the same package

Thats not very private then is it.

>
> 2) have another attribute: 'package'.
>
> I prefer (1) to avoid a proliferation of keywords and complexity with
little
> added value.
>

I would prefer package access to be "protected"
as in Java, and private access for class only access.

Phill.

On Tue, 01 Jun 2004 19:26:08 -0400, Ben Hinkle wrote:

> Walter wrote:
> 
>> There are two ways to provide package level 'friend' access:
>> 
>> 1) simply allow private members to be accessed from other modules in the same package
>> 
>> 2) have another attribute: 'package'.
>> 
>> I prefer (1) to avoid a proliferation of keywords and complexity with
>> little added value.
> 
> 1 is nice except it is a pity to lose the ability to have "really private"
> declarations. For example would this affect optimizations when the compiler
> has to assume a given symbol can be accessed from outside the file it is
> currently compiling?
> One way to help here is to take the public/private to the module
> declaration. If the "private" keyword is before the "module" keyword then
> all the private declaration in the module are truly private and public
> declarations are "package". Otherwise by default the private declarations
> are "package" as you propose and public is the same as it is now: public
> everywhere. For example
> 
> file pkg/foo.d:
> private module pkg.foo;
> private int a;  // only visible in foo.d
> int a2;         // visible in foo.d and bar.d but not outside pkg
> 
> file pkg/bar.d:
> module pkg.bar;
> private int b;  // visible in bar.d and foo.d but not outside pkg
> int b2;         // visible anywhere

I like this idea, Ben. I was concerned that to enforce real privacy we would have to have single-file folders (packages with a single module) which would lead to other organizational headaches. Your suggestion removes that necessity.

Also, it implies that the author of the module has responsibilty of the module's contents/usage rather than the author of the package. Because to create a package all we have to do is move modules into an operating system folder! In your system, if a package author really needs to access the private members from other modules in the same package, then they need to explictly remove the 'private' prefix to the 'module' declaration.

-- 
Derek
2/Jun/04 10:15:48 AM

"Phill" <phill@pacific.net.au> wrote in message news:c9j5uk$2pgk$1@digitaldaemon.com...
> I would prefer package access to be "protected"
> as in Java, and private access for class only access.

That isn't my understanding of Java. Java has private, package, protected and public. The package protection doesn't have a keyword, it's the default, but it is distinct from protected.

Andy Friesen wrote:
> Instinctively, I prefer the second choice, but I'm having a hard time rationalizing it.

Okay I think I know why now.

A big part of D's design is to make it simple to write rigorously safe, obsessively correct programs.  It seems a matter of course that it be simple to describe pieces of a class that must only be used within the class itself.

If private isn't really private, then the only recourse is to either make many, many packages, or to write final classes and to make those 'private' things protected instead.

 -- andy

"Ben Hinkle"  wrote
> 1 is nice except it is a pity to lose the ability to have "really private" declarations. For example would this affect optimizations when the
compiler
> has to assume a given symbol can be accessed from outside the file it is
> currently compiling?
> One way to help here is to take the public/private to the module
> declaration. If the "private" keyword is before the "module" keyword then
> all the private declaration in the module are truly private and public
> declarations are "package". Otherwise by default the private declarations
> are "package" as you propose and public is the same as it is now: public
> everywhere. For example
>
> file pkg/foo.d:
> private module pkg.foo;
> private int a;  // only visible in foo.d
> int a2;         // visible in foo.d and bar.d but not outside pkg
>
> file pkg/bar.d:
> module pkg.bar;
> private int b;  // visible in bar.d and foo.d but not outside pkg
> int b2;         // visible anywhere

I like your idea about private modules Ben. But that second example gives me the chills. I mean, private should mean "you don't get to access this directly"; full stop. It's one thing breaking that rule within the same body of code (module) but quite another to break it for any other module that happens to be in the same directory. Especially so if it were the default behavior (sans private).

What do you think about using the protected keyword on the module instead, which would open up all protected attributes to package scope? In other words, the default module access would be as it currently is; effectively private. You have to explicitly override that to open up attribute scope ...

Still, I think I'd vote for a 'package' keyword. It just has a better "feel" to it though, like others, I can't say exactly why.

- Kris

I prefer the Java way . When you don't have any accessor such as public
private or protected , the method will become protected - package . Because
all of us are coming from C++ or Java/C# , so I believe all of us have a
habit which define accessor before variable , or method . So what we don't
define , it will be friend among classes in package .
"Hauke Duden" <H.NS.Duden@gmx.net> wrote in message
news:c9iu3u$2ecf$1@digitaldaemon.com...
> Arcane Jill wrote:
> > In article <c9ipvn$28dc$1@digitaldaemon.com>, Walter says...
> >
> >>There are two ways to provide package level 'friend' access:
> >>
> >>1) simply allow private members to be accessed from other modules in the same package
> >>
> >>2) have another attribute: 'package'.
> >>
> >>I prefer (1) to avoid a proliferation of keywords and complexity with
little
> >>added value.
> >
> >
> > I would be quite happy with that, but before you commit yourself, please
be
> > aware that there is a third option. The Java way. This is: if neither
"private"
> > not "protected" nor "public" is specified, then it's package-visible. In
Java,
> > package-visibility is the default, and it seems mighty sensible to me.
"public"
> > (to my mind) should have to be explicitly specified.
>
> I don't agree. The cases when something has to be package are usually rare (at least in my code), so why should it be the default?
>
> As to which of Walter's options I'd prefer:
>
> I think I'd go for number 2. I just have a bad feeling about allowing every class or function in the package to access everything of every other class.
>
> Now that I think about it: there's also a good reason against 1. If access to protected members of other classes in the same package is automatically allowed then it is possible to use internal methods by accident. Maybe the internal method has a similar argument list or the caller just didn't realize that it is protected when he looked over the class. It should be possible to prevent such things, so I vote for an explicit package attribute.
>
> Hauke

On Wed, 2 Jun 2004 13:46:26 +0700, Tu Nam wrote:

> I prefer the Java way . When you don't have any accessor such as public private or protected , the method will become protected - package . Because all of us are coming from C++ or Java/C# , so I believe all of us have a habit which define accessor before variable , or method . So what we don't define , it will be friend among classes in package .

I'm not coming from C++ or Java/C#, so I don't have this 'habit'. My bias and habits have not been forged by C++/C#/Java, so I'm coming to D with a relatively open mind about these things.

-- 
Derek
2/Jun/04 4:53:10 PM