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/

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

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

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

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

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.

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)

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