www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - package vs module access

reply "Walter" <newshound digitalmars.com> writes:
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.
Jun 01 2004
next sibling parent reply "Vathix" <vathixSpamFix dprogramming.com> writes:
"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

 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.
Jun 01 2004
parent DemmeGod <me demmegod.com> writes:
 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
Jun 01 2004
prev sibling next sibling parent reply Regan Heath <regan netwin.co.nz> writes:
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/
Jun 01 2004
next sibling parent reply DemmeGod <me demmegod.com> writes:
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?

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.


Jun 01 2004
parent reply Regan Heath <regan netwin.co.nz> writes:
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?

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/
Jun 01 2004
parent DemmeGod <me demmegod.com> writes:
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?

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)
Jun 01 2004
prev sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
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
Jun 01 2004
parent DemmeGod <me demmegod.com> writes:
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

Jun 01 2004
prev sibling next sibling parent reply Andy Friesen <andy ikagames.com> writes:
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
Jun 01 2004
parent Andy Friesen <andy ikagames.com> writes:
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
Jun 01 2004
prev sibling next sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
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
Jun 01 2004
parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
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
Jun 01 2004
next sibling parent reply "Tu Nam" <dreamweaver mail15.com> writes:
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



added value.

I would be quite happy with that, but before you commit yourself, please


 aware that there is a third option. The Java way. This is: if neither


 not "protected" nor "public" is specified, then it's package-visible. In


 package-visibility is the default, and it seems mighty sensible to me.


 (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

Jun 01 2004
parent reply Derek Parnell <derek psych.ward> writes:
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
Jun 01 2004
parent "Tu Nam" <dreamweaver mail15.com> writes:
Only assembly and functional ( Scheme , Ocaml ) men are don't have that
habit ;) j/k
BTW, it's just proposition , it depend on Walter who decide which way to
implement .

"Derek Parnell" <derek psych.ward> wrote in message
news:c9jtml$q4e$1 digitaldaemon.com...
 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 .


 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


 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

Jun 02 2004
prev sibling parent reply Ben Hinkle <bhinkle4 juno.com> writes:
Hauke Duden wrote:

 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?

I agree it shouldn't be the default. I get annoyed with all the "public"s that have to be thrown into Java. It just adds clutter.
 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 

The argument list shouldn't matter since overloading doesn't take place without making an alias (Walter is a wise dude). The only way to accidentally call the other method is to mistype a function name at the call site and the mistyped name happened to match the name of some imported private function. This seems pretty rare.
 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

Why is it so important to prevent the call? The most important usage of protection attributes is to prevent *user code* from calling a given function. Since the same group that develops a module is probably developing the whole package the biggest difference I can think of that this makes is one will have to search the entire package if you want to change a private function name or API whereas previously one only had the search the file. Not such a big deal. One question: if a user makes a directory std/foo.d somewhere on the include path does foo.d have access to all the privates of the "real" std package? -Ben
Jun 02 2004
parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
Ben Hinkle wrote:
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 

The argument list shouldn't matter since overloading doesn't take place without making an alias (Walter is a wise dude). The only way to accidentally call the other method is to mistype a function name at the call site and the mistyped name happened to match the name of some imported private function. This seems pretty rare.

No, I meant something like this: class Foo { int foo(int i); protected: int foo(int i,int j); //more complicated version, possibly //used for recursive implementation //of foo. } If code in another class of the same package wants to call the public foo, but the programmer accidentally only stumbled over the protected one (maybe because the class is big) without realizing that it is protected then blanket access to everything would allow this error to go unnoticed. It also leaves lots of room for hacking. There is a type of programmer that will just use the first way that occurs to him and that happens to compile. Some people just don't understand that, for example, a comment like DO NOT USE - BEHAVIOUR WILL CHANGE LATER means "do not use!". You get answers like "I tested it once and it worked". The fact that there is a reason for such a comment is beyond them. Those people and accidental use of internal functions are the main reasons why we have access levels. And they also apply to package scope. So we need a way to protect module members from other modules in the same package. And Walter's option (2) seems to be the best way to do that.
 Why is it so important to prevent the call? The most important usage of
 protection attributes is to prevent *user code* from calling a given
 function. Since the same group that develops a module is probably
 developing the whole package the biggest difference I can think of that
 this makes is one will have to search the entire package if you want to
 change a private function name or API whereas previously one only had the
 search the file. Not such a big deal.

Heh. Obviously you haven't worked in a big enough group yet ;). At some point it cannot be guaranteed anymore that everyone knows how everything works internally. People know their own code and how to USE the code of others and that's it. So "user code" can also be code in the same package. And, of course there are also the "less experienced" team members I mentioned above ;). Hauke
Jun 02 2004
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"Hauke Duden" <H.NS.Duden gmx.net> wrote in message
news:c9kpjv$237k$1 digitaldaemon.com...
 Ben Hinkle wrote:
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

The argument list shouldn't matter since overloading doesn't take place without making an alias (Walter is a wise dude). The only way to accidentally call the other method is to mistype a function name at the call site and the mistyped name happened to match the name of some


 private function. This seems pretty rare.

No, I meant something like this: class Foo { int foo(int i); protected: int foo(int i,int j); //more complicated version, possibly //used for recursive implementation //of foo. } If code in another class of the same package wants to call the public foo, but the programmer accidentally only stumbled over the protected one (maybe because the class is big) without realizing that it is protected then blanket access to everything would allow this error to go unnoticed.

I don't think Walter is proposing that "protected" members get package access. He just proposed that "private" change. "Protected" and "public" will stay the same. Related to "protected": as a keyword I think "protected" isn't descriptive. I know Java uses it and Walter most likely won't change it but having a section in the doc about "protection attributes" and one of the protection levels is "protected" seems like a busted vocabulary. It's like having a modifier called "modified". I don't have a suggestion for a better word, though. I'm just rambling :-)
Jun 02 2004
parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
Ben Hinkle wrote:
 I don't think Walter is proposing that "protected" members get package
 access. He just proposed that "private" change. "Protected" and "public"
 will stay the same.

What do you mean? Protected is a less-restrictive access level than private. Surely with option (1) Walter doesn't want to allow access to private members, but deny access to protected members? It doesn't really matter for option (2), though. Then neither protected nor private entities will be accessible from outside (well, protected will be if the class is a subclass), but "package" entities will. I think the discussion indicates that "package" will be easier to understand ;).
 Related to "protected": as a keyword I think "protected" isn't descriptive.
 I know Java uses it and Walter most likely won't change it but having a
 section in the doc about "protection attributes" and one of the protection
 levels is "protected" seems like a busted vocabulary. It's like having a
 modifier called "modified". I don't have a suggestion for a better word,
 though. I'm just rambling :-)

Why? "Public" means public free-for-all. "Protected" means not completely public but ... protected so that only subclasses can access it. And "private" is the ultimate "ALL MINE, HAR HAR" access level. Seems intuitive to me, but maybe I'm just spoilt from using them for so long ;). Hauke
Jun 02 2004
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
 Related to "protected": as a keyword I think "protected" isn't


 I know Java uses it and Walter most likely won't change it but having a
 section in the doc about "protection attributes" and one of the


 levels is "protected" seems like a busted vocabulary. It's like having a
 modifier called "modified". I don't have a suggestion for a better word,
 though. I'm just rambling :-)

Why? "Public" means public free-for-all. "Protected" means not completely public but ... protected so that only subclasses can access it. And "private" is the ultimate "ALL MINE, HAR HAR" access level. Seems intuitive to me, but maybe I'm just spoilt from using them for so long ;).

But how does someone have any clue what "protected" means without reading the language spec or knowing Java? The phrases "public protection" and "private protection" sound fine but "protected protection" sounds goofy. It's like a Laurel and Hardy sketch: Laurel: What the protection? Hardy: Protected. Laurel. I know it's protected, but what protection? Hardy: Protected! etc etc
Jun 02 2004
next sibling parent Hauke Duden <H.NS.Duden gmx.net> writes:
Ben Hinkle wrote:

Related to "protected": as a keyword I think "protected" isn't


descriptive.
I know Java uses it and Walter most likely won't change it but having a
section in the doc about "protection attributes" and one of the


protection
levels is "protected" seems like a busted vocabulary. It's like having a
modifier called "modified". I don't have a suggestion for a better word,
though. I'm just rambling :-)

Why? "Public" means public free-for-all. "Protected" means not completely public but ... protected so that only subclasses can access it. And "private" is the ultimate "ALL MINE, HAR HAR" access level. Seems intuitive to me, but maybe I'm just spoilt from using them for so long ;).

But how does someone have any clue what "protected" means without reading the language spec or knowing Java? The phrases "public protection" and "private protection" sound fine but "protected protection" sounds goofy. It's like a Laurel and Hardy sketch: Laurel: What the protection? Hardy: Protected. Laurel. I know it's protected, but what protection? Hardy: Protected!

LOL But seriously, how do you know what "private" means? Or "for"? You must have some knowledge for that - the key is to make it easy to remember it. And consistency with other languages cannot hurt. Since C++, JAVA, D and (I think) C# all use pretty much the same access identifiers it's easy. Hauke
Jun 02 2004
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Ben Hinkle" <bhinkle mathworks.com> wrote in message
news:c9l32r$2h7g$1 digitaldaemon.com...
 But how does someone have any clue what "protected" means without reading
 the language spec or knowing Java?

I hear you and agree with the sentiment, but 'protected' has a well established meaning from both C++ and Java, and the meaning is well-developed and consistent between the two languages. Therefore, I think D's 'protected' should match it and have the expected behavior.
Jun 02 2004
parent "Ben Hinkle" <bhinkle mathworks.com> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:c9l89o$2p51$1 digitaldaemon.com...
 "Ben Hinkle" <bhinkle mathworks.com> wrote in message
 news:c9l32r$2h7g$1 digitaldaemon.com...
 But how does someone have any clue what "protected" means without


 the language spec or knowing Java?

I hear you and agree with the sentiment, but 'protected' has a well established meaning from both C++ and Java, and the meaning is well-developed and consistent between the two languages. Therefore, I

 D's 'protected' should match it and have the expected behavior.

ah - I forgot C++ had protected. I guess that shows how often I use it :-)
Jun 02 2004
prev sibling next sibling parent reply Ben Hinkle <bhinkle4 juno.com> writes:
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
Jun 01 2004
next sibling parent Derek Parnell <derek psych.ward> writes:
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
Jun 01 2004
prev sibling next sibling parent "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
"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

 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
Jun 01 2004
prev sibling parent "Ivan Senji" <ivan.senji public.srce.hr> writes:
"Ben Hinkle" <bhinkle4 juno.com> wrote in message
news:c9j3ad$2lvp$1 digitaldaemon.com...
 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

 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

Thinking about this proposal i am begining to like it more and more. When you think about it: it is so D style. In classes the default is public and if you want it to be private you have to write it. Your way it would be the same for modules/packages: If you don't write public: then every module in a package can access everything: public and private, but if you really wan't module's privates to be private you just write private module and that is it! I think this would be the best way to do it. Far better than introducing new keywords, and would solve a problem when someone doesn't what everything in a package to have access to everything else in the package. Hope Walter seriously thinks about this one. :)
 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

Jun 04 2004
prev sibling next sibling parent reply "Phill" <phill pacific.net.au> writes:
"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

 added value.

I would prefer package access to be "protected" as in Java, and private access for class only access. Phill.
Jun 01 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"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.
Jun 01 2004
parent reply "Phill" <phill pacific.net.au> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:c9j7e1$2rjb$1 digitaldaemon.com...
 "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

 but it is distinct from protected.

Yep im aware that with protected you get package(folder) access and also the subclasses have access, whereas package is only package access and is the default. When I said "as in Java" I meant I think it would be good if D had package access but this access included access to the subclasses as well, the same as Java's protected access. I still think that your first option is like walking around your house with no clothes on(not very private) especially when friends drop by. But then again thats up to you. Phill.
Jun 02 2004
next sibling parent reply Andy Friesen <andy ikagames.com> writes:
Phill wrote:

 When I said "as in Java" I meant I think it would be good if  D had package
 access but this access included access
 to the subclasses as well, the same as  Java's protected access.

Managed C++ has something like this, though it manages to fudge the syntax spectacularly. 'public private' attributes are public within an assembly, private outside. 'public protected' behave as you describe--public within the assembly, protected outside.
 I still think that your first option is like walking around your house with
 no clothes on(not very private) especially when
 friends drop by. But then again thats up to you.

I agree. Given D's emphasis on DbC, it seems somewhat inconsistent to lack something so basic as a way to prevent other classes from accessing implementation details. -- andy
Jun 02 2004
parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
Andy Friesen wrote:
 When I said "as in Java" I meant I think it would be good if  D had 
 package
 access but this access included access
 to the subclasses as well, the same as  Java's protected access.

Managed C++ has something like this, though it manages to fudge the syntax spectacularly. 'public private' attributes are public within an assembly, private outside. 'public protected' behave as you describe--public within the assembly, protected outside.

Yuk! How about generalizing this and specifying access levels? "public private private" means public on package level, private on module level and private for subclasses. Would apply to something like an exhibitionistic introvert class ;). And NO, that wasn't a serious suggestion ;). Hauke
Jun 02 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"Hauke Duden" <H.NS.Duden gmx.net> wrote in message
news:c9kv63$2bm6$1 digitaldaemon.com...
 Yuk! How about generalizing this and specifying access levels? "public
 private private" means public on package level, private on module level
 and private for subclasses. Would apply to something like an
 exhibitionistic introvert class ;).

 And NO, that wasn't a serious suggestion ;).

It seems to be pretty wretched to start defining semantics for "public private". I'd rather have a new keyword.
Jun 02 2004
parent reply Andy Friesen <andy ikagames.com> writes:
Walter wrote:
 "Hauke Duden" <H.NS.Duden gmx.net> wrote in message
 news:c9kv63$2bm6$1 digitaldaemon.com...
 
Yuk! How about generalizing this and specifying access levels? "public
private private" means public on package level, private on module level
and private for subclasses. Would apply to something like an
exhibitionistic introvert class ;).

And NO, that wasn't a serious suggestion ;).

It seems to be pretty wretched to start defining semantics for "public private". I'd rather have a new keyword.

It was either that or even more underscores. ;) Managed C++ is a great example of how much further C++ can go without breaking compatibility. Especially the syntax for handling pointers, arrays, and functions returning same. System::String __gc* MyClass::method() __gc[] { ... } (same as string[] method() { ... } in C#) -- andy
Jun 02 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"Andy Friesen" <andy ikagames.com> wrote in message
news:c9l9d7$2qt2$1 digitaldaemon.com...
 Managed C++ is a great example of how much further C++ can go without
 breaking compatibility.  Especially the syntax for handling pointers,
 arrays, and functions returning same.

 System::String __gc* MyClass::method() __gc[] { ... }

Sorry, I see that as similar to the bad old days of __far and __near <g>.
Jun 02 2004
parent Andy Friesen <andy ikagames.com> writes:
Walter wrote:
 "Andy Friesen" <andy ikagames.com> wrote in message
 news:c9l9d7$2qt2$1 digitaldaemon.com...
 
Managed C++ is a great example of how much further C++ can go without
breaking compatibility.  Especially the syntax for handling pointers,
arrays, and functions returning same.

System::String __gc* MyClass::method() __gc[] { ... }

Sorry, I see that as similar to the bad old days of __far and __near <g>.

I guess the sarcasm wasn't obvious enough. ;) -- andy
Jun 02 2004
prev sibling parent reply Regan Heath <regan netwin.co.nz> writes:
On Wed, 2 Jun 2004 20:45:03 +1000, Phill <phill pacific.net.au> wrote:
 I still think that your first option is like walking around your house 
 with
 no clothes on(not very private) especially when
 friends drop by. But then again thats up to you.

It's a known fact that (in C++) friends have access to your privates. :) -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jun 02 2004
parent "Phill" <phill pacific.net.au> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message
news:opr8zpuhn15a2sq9 digitalmars.com...
 On Wed, 2 Jun 2004 20:45:03 +1000, Phill <phill pacific.net.au> wrote:
 I still think that your first option is like walking around your house
 with
 no clothes on(not very private) especially when
 friends drop by. But then again thats up to you.

It's a known fact that (in C++) friends have access to your privates. :)

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

Jun 02 2004
prev sibling next sibling parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"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

 added value.

Yet more brainstorming... Any chance of following the model of extern http://www.digitalmars.com/d/attribute.html#linkage and putting the specific type of protection in parens? Something like private(package) private(subclass) == protected today private(module) == private today If there aren't any parens then "module" would be default just like the current behavior. I'd deprecate the "protected" keyword since "private(subclass)" is much more descriptive of the behavior. One difference from extern is that implementation wouldn't be able to add more protection styles.
Jun 02 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"Ben Hinkle" <bhinkle mathworks.com> wrote in message
news:c9l4kg$2jj6$1 digitaldaemon.com...
 Yet more brainstorming...

 Any chance of following the model of extern
 http://www.digitalmars.com/d/attribute.html#linkage
 and putting the specific type of protection in parens? Something like

  private(package)
  private(subclass) == protected today
  private(module) == private today

 If there aren't any parens then "module" would be default just like the
 current behavior.
 I'd deprecate the "protected" keyword since "private(subclass)" is much

 descriptive of the behavior.

 One difference from extern is that implementation wouldn't be able to add
 more protection styles.

There is no technical problem with that, but just brainstorming, I'd rather see an: access(private) access(public) access(package) for consistency. But it just seems a bit wordy.
Jun 02 2004
next sibling parent Patrick Down <Patrick_member pathlink.com> writes:
In article <c9l7mi$2o5d$3 digitaldaemon.com>, Walter says...
"Ben Hinkle" <bhinkle mathworks.com> wrote in message
news:c9l4kg$2jj6$1 digitaldaemon.com...
 Yet more brainstorming...

 Any chance of following the model of extern
 http://www.digitalmars.com/d/attribute.html#linkage
 and putting the specific type of protection in parens? Something like

  private(package)
  private(subclass) == protected today
  private(module) == private today

 If there aren't any parens then "module" would be default just like the
 current behavior.
 I'd deprecate the "protected" keyword since "private(subclass)" is much

 descriptive of the behavior.

 One difference from extern is that implementation wouldn't be able to add
 more protection styles.

There is no technical problem with that, but just brainstorming, I'd rather see an: access(private) access(public) access(package) for consistency. But it just seems a bit wordy.

This would get my vote.
Jun 02 2004
prev sibling next sibling parent reply Mike Swieton <mike swieton.net> writes:
On Wed, 02 Jun 2004 11:49:31 -0700, Walter wrote:
 There is no technical problem with that, but just brainstorming, I'd rather
 see an:
     access(private)
     access(public)
     access(package)
 for consistency. But it just seems a bit wordy.

I'll throw a vote behind that. I don't think wordiness is too much of a problem, since you'd be able to: class Foo { access(public): this() {} access(private): int that() { return 0; } } Heh, start's to look like python. But seriously, I think that wordiness would only be a problem for people going Java style and speccing it on every member. Mike Swieton __ Our earth is degenerate in these latter days. Bribery and corruption are common. Children no longer obey their parents. Every man wants to write a book... The end of the world is evidently approaching. - On a stone slab carved in 2800 B.C. in Assyria
Jun 02 2004
parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
There is no technical problem with that, but just brainstorming, I'd rather
see an:
    access(private)
    access(public)
    access(package)
for consistency. But it just seems a bit wordy.


It also reduces the scannability of the code. Human beings read by recognizing the first few and the last characters of a word and interpolating from that. Words that have the same prefix are less easy to recognize than others. And, more importantly, I don't like the brackets ;). D has already more than enough round brackets if you ask me. And since these will be on the same level as method definitions you'd always have to look twice to see if it's a method or an access modifier. Hauke
Jun 02 2004
parent "Bruno A. Costa" <bruno codata.com.br> writes:
Hauke Duden wrote:

There is no technical problem with that, but just brainstorming, I'd
rather see an:
    access(private)
    access(public)
    access(package)
for consistency. But it just seems a bit wordy.


It also reduces the scannability of the code. Human beings read by recognizing the first few and the last characters of a word and interpolating from that. Words that have the same prefix are less easy to recognize than others. And, more importantly, I don't like the brackets ;). D has already more than enough round brackets if you ask me. And since these will be on the same level as method definitions you'd always have to look twice to see if it's a method or an access modifier. Hauke

Agreed. Bruno.
Jun 03 2004
prev sibling parent reply "Phill" <phill pacific.net.au> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:c9l7mi$2o5d$3 digitaldaemon.com...
 "Ben Hinkle" <bhinkle mathworks.com> wrote in message
 news:c9l4kg$2jj6$1 digitaldaemon.com...
 Yet more brainstorming...

 Any chance of following the model of extern
 http://www.digitalmars.com/d/attribute.html#linkage
 and putting the specific type of protection in parens? Something like

  private(package)
  private(subclass) == protected today
  private(module) == private today

 If there aren't any parens then "module" would be default just like the
 current behavior.
 I'd deprecate the "protected" keyword since "private(subclass)" is much

 descriptive of the behavior.

 One difference from extern is that implementation wouldn't be able to


 more protection styles.

There is no technical problem with that, but just brainstorming, I'd

 see an:
     access(private)
     access(public)
     access(package)
 for consistency. But it just seems a bit wordy.

Does this mean that there is no in between private and public? Like if a subclass has to access its parent outside of the package, its parents methods and variables have to be public to be used? Phill
Jun 02 2004
parent "Walter" <newshound digitalmars.com> writes:
"Phill" <phill pacific.net.au> wrote in message
news:c9llif$bfu$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in message
 There is no technical problem with that, but just brainstorming, I'd

 see an:
     access(private)
     access(public)
     access(package)
 for consistency. But it just seems a bit wordy.

Does this mean that there is no in between private and public? Like if a subclass has to access its parent outside of the package, its parents methods and variables have to be public to be used?

There's currently 'protected' for that.
Jun 02 2004
prev sibling parent Marco A <Marco_member pathlink.com> writes:
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.

visibility to other modules/classes in the same package for functions and data. Hopefully using "protected" visibility would be quite rare. ==================================== Suggested document/nomenclature change change "Protection Attribute" to "Visibility Attribute" (UML speak)
Jun 03 2004