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

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

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

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

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

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

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

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

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

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