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

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

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

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

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.

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

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

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

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

"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