Thread overview | ||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
June 01, 2004 package vs module access | ||||
---|---|---|---|---|
| ||||
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. |
June 01, 2004 Re: package vs module access | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | "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. |
June 01, 2004 Re: package vs module access | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | 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/ |
June 01, 2004 Re: package vs module access | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | 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
|
June 01, 2004 Re: package vs module access | ||||
---|---|---|---|---|
| ||||
Posted in reply to Regan Heath | 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. |
June 01, 2004 Re: package vs module access | ||||
---|---|---|---|---|
| ||||
Posted in reply to Vathix | > 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
|
June 01, 2004 Re: package vs module access | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | 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 |
June 01, 2004 Re: package vs module access | ||||
---|---|---|---|---|
| ||||
Posted in reply to DemmeGod | 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/ |
June 01, 2004 Re: package vs module access | ||||
---|---|---|---|---|
| ||||
Posted in reply to Regan Heath | 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 |
June 01, 2004 Re: package vs module access | ||||
---|---|---|---|---|
| ||||
Posted in reply to Arcane 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
|
Copyright © 1999-2021 by the D Language Foundation