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


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.
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?


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.
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?


 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/
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?


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

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
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

 habit which define accessor before variable , or method . So what we don't
 define , it will be friend among classes in package .




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 .




Because


 habit which define accessor before variable , or method . So what we




don't

 define , it will be friend among classes in package .




 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




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.


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




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!

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 


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




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.


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


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
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


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


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


little

 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


default,

 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[] { ... }



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


yes I forgot to write "pardon the pun"



 --
 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


little

 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


more

 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


more

 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


 more

 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.


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


 rather

 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.


It seems "protected" at the module or class level could provide "package"
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