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.

"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
>
> 2) have another attribute: 'package'.
>
> I prefer (1) to avoid a proliferation of keywords and complexity with
little
> added value.
>

I like how D is less private with access than C++, but (1) might be a bit
too far. People might be forced to create a bunch of packages for their
code; creating more directories/files appears to be the opposite of your
module philosophy.
If (2) is chosen, I suggest treating "protected package" to allow package
access and access to derived classes.

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?

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

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

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) smells a bit too willy-nilly to me at first thought, but it would only really come into play on a relatively small scale.  Any application large enough to really need such rigorous encapsulation will undoubtedly be split into multiple packages anyway.

Instinctively, I prefer the second choice, but I'm having a hard time rationalizing it.

On an unrelated note, it's kind of funny that, unlike C++, D's protected access modifier is actually stricter than private in a lot of ways.

 -- andy

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.
> 
>> 2) have another attribute: 'package'.
>>
>> I prefer (1) to avoid a proliferation of keywords and complexity with
>> little added value.

> If (2) is chosen, I suggest treating "protected package" to allow package access and access to derived classes.

Seconded.  The devired class should also be able to specify "package" to allow modules in it's package to access it, if this isn't already implied.

John

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.

Jill

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?

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

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.

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").

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

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