Derek Parnell wrote:
> On Mon, 30 Jan 2006 16:52:47 -0800, Walter Bright wrote:
> 
> 
>>"Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message news:drm5ij$13eu$1@digitaldaemon.com...
>>
>>>class A
>>>{
>>>this()
>>>{
>>> b = new B();
>>> b.x = 5; // illegal
>>>}
>>>
>>>class B
>>>{
>>> protected int x;
>>>}
>>>
>>>B b;
>>>}
>>>
>>>FIX THIS.
>>
>>First I want to ask why is B.x given protected? The reason I ask is this is also an error in C++, and there's a lot of water under the bridge for it.
> 
> 
> Aside from whether this is 'protected', 'private' or 'package', if you make
> 'B' a non-nested class, it compiles just fine. So it seems that it just the
> nesting that is causing the inconsistency.
> 
> We are just starting to get used to the idea that everything is accessible
> to anything in the same module. But nesting seems to be an exception. Why?
> 
Are we (getting used)? I can't say I'm totally sure, as I would need more pratical experience, but I think I would prefer scope-wise protection, instead of module-wise. It doesn't seem natural.
Still, as Walter announced, at least the inconsistency will be fixed, which is better, even if the fix will be to complete module-wise protection.

-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to be... unnatural."

On Tue, 31 Jan 2006 20:04:49 +0000, Bruno Medeiros wrote:

> Derek Parnell wrote:
>> On Mon, 30 Jan 2006 16:52:47 -0800, Walter Bright wrote:
>> 
>>>"Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message news:drm5ij$13eu$1@digitaldaemon.com...
>>>
>>>>class A
>>>>{
>>>>this()
>>>>{
>>>> b = new B();
>>>> b.x = 5; // illegal
>>>>}
>>>>
>>>>class B
>>>>{
>>>> protected int x;
>>>>}
>>>>
>>>>B b;
>>>>}
>>>>
>>>>FIX THIS.
>>>
>>>First I want to ask why is B.x given protected? The reason I ask is this is also an error in C++, and there's a lot of water under the bridge for it.
>> 
>> Aside from whether this is 'protected', 'private' or 'package', if you make 'B' a non-nested class, it compiles just fine. So it seems that it just the nesting that is causing the inconsistency.
>> 
>> We are just starting to get used to the idea that everything is accessible to anything in the same module. But nesting seems to be an exception. Why?
>> 
> Are we (getting used)?

(Sprung!) Yes, I did use the 'royal' "we".

>I can't say I'm totally sure, as I would need
> more pratical experience, but I think I would prefer scope-wise
> protection, instead of module-wise. It doesn't seem natural.
> Still, as Walter announced, at least the inconsistency will be fixed,
> which is better, even if the fix will be to complete module-wise protection.

But isn't a module also a scope? Or to say differently, doesn't a module have a scope?

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
1/02/2006 9:52:55 AM

"Bruno Medeiros" <daiphoenixNO@SPAMlycos.com> wrote in message news:drofos$1mnf$1@digitaldaemon.com...
> I think I would prefer scope-wise protection, instead of module-wise. It doesn't seem natural.

I like the current scheme - some classes just need to work together, and I think the module-friend-ness is an elegant, if not a little confusing-at-first, solution to that.  This way, you put classes that you want to be able to work together without hassle in the same module, and then they kind of function as a unit.

Wondering, what would be your perferred method of protection when you want classes to work together?  I thought that "friend" worked pretty well in C++, although it was kind of cumbersome.

"Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message news:drove4$287r$1@digitaldaemon.com...
> I like the current scheme - some classes just need to work together, and I think the module-friend-ness is an elegant, if not a little confusing-at-first, solution to that.

I agree it's elegant, and the only reason it might be initially confusing is because it isn't how things work in C++ or Java.

> This way, you put classes that you want to be able to work together without hassle in the same module, and then they kind of function as a unit.

Yup.

> Wondering, what would be your perferred method of protection when you want classes to work together?  I thought that "friend" worked pretty well in C++, although it was kind of cumbersome.

I've never liked the 'friend' thing in C++, it's a wretched kludge to work around the lack of module scoping. (Of course, C++ later added namespaces, but namespaces just don't seem to have caught on, and missed the opportunity to deprecate friends.)

In article <drp87e$2hai$2@digitaldaemon.com>, Walter Bright says...
>
>
>"Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message news:drove4$287r$1@digitaldaemon.com...
>> I like the current scheme - some classes just need to work together, and I think the module-friend-ness is an elegant, if not a little confusing-at-first, solution to that.
>
>I agree it's elegant, and the only reason it might be initially confusing is because it isn't how things work in C++ or Java.
>
>> This way, you put classes that you want to be able to work together without hassle in the same module, and then they kind of function as a unit.
>
>Yup.

I don't like having someone access my private member, even if it' in my same
unit ;-).
I think Java has a cleaner approach to this issue, thoug they don't want to add
a simple 'package' keyword to their declarations.

Ciao

Derek Parnell wrote:
> On Tue, 31 Jan 2006 20:04:49 +0000, Bruno Medeiros wrote:
> 
> 
>>Derek Parnell wrote:
>>
>>>On Mon, 30 Jan 2006 16:52:47 -0800, Walter Bright wrote:
>>>
>>>
>>>>"Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message news:drm5ij$13eu$1@digitaldaemon.com...
>>>>
>>>>
>>>>>class A
>>>>>{
>>>>>this()
>>>>>{
>>>>>b = new B();
>>>>>b.x = 5; // illegal
>>>>>}
>>>>>
>>>>>class B
>>>>>{
>>>>>protected int x;
>>>>>}
>>>>>
>>>>>B b;
>>>>>}
>>>>>
>>>>>FIX THIS.
>>>>
>>>>First I want to ask why is B.x given protected? The reason I ask is this is also an error in C++, and there's a lot of water under the bridge for it.
>>>
>>>Aside from whether this is 'protected', 'private' or 'package', if you make
>>>'B' a non-nested class, it compiles just fine. So it seems that it just the
>>>nesting that is causing the inconsistency.
>>>
>>>We are just starting to get used to the idea that everything is accessible
>>>to anything in the same module. But nesting seems to be an exception. Why?
>>>
>>
>>Are we (getting used)? 
> 
> 
> (Sprung!) Yes, I did use the 'royal' "we".
> 
> 
>>I can't say I'm totally sure, as I would need more pratical experience, but I think I would prefer scope-wise protection, instead of module-wise. It doesn't seem natural.
>>Still, as Walter announced, at least the inconsistency will be fixed, which is better, even if the fix will be to complete module-wise protection.
> 
> 
> But isn't a module also a scope? Or to say differently, doesn't a module
> have a scope?
> 
Yes, of course! But by scope-wise I was refering to the immediate (i.e. innermost) scope where the entity is declared.
Indeed, now that you made me think about it, "scope-wise" may not be the best term for it. (boy, don't I just love terminology .. )

-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to be... unnatural."

Jarrett Billingsley wrote:
> "Bruno Medeiros" <daiphoenixNO@SPAMlycos.com> wrote in message news:drofos$1mnf$1@digitaldaemon.com...
> 
>>I think I would prefer scope-wise protection, instead of module-wise. It doesn't seem natural.
> 
> 
> I like the current scheme - some classes just need to work together, and I think the module-friend-ness is an elegant, if not a little confusing-at-first, solution to that.  This way, you put classes that you want to be able to work together without hassle in the same module, and then they kind of function as a unit.
> 
> Wondering, what would be your perferred method of protection when you want classes to work together?  I thought that "friend" worked pretty well in C++, although it was kind of cumbersome. 
> 
> 

I don't know, I don't recall being bugged by such problem.
How do other languages deal with this? Java and C# don't have a protection level like that, as the nearest they have to private (excluding private itself) is respectively, package and internal ('internal' being: accessible within the assembly). And I don't hear people complain about it. Wouldn't D's 'package' protection suffice for this?

I really don't like when it (D) goes against what is common in the trio of disparate languages that is C++, Java and C#. Usually the things that are common among these three (and even among other languages) are the things that standard and/or well-done/well-tought. Remember in the "C++ vs Java vs Python vs Ruby" article the comment "Why does Ruby use rescue/ensure when the rest of the world has settled on try/catch/finally"?
I think we should strive for consistency in the things that are standard amongst many languages, unless there is a good reason not to.

So again I ask, is there a good reason not to? Wouldn't D's package protection suffice for this? Don't Java and C# face this problem? (C# is even "worse" in that 'internal' is even less restrictive than 'package'.)

If even so you think we should have such a access protection level, why not just make a new keyword for it? Like 'restricted' or 'internal' (would not be the same as C#'s 'internal', yes) or something else. Thus we would have 'private' work as immediate-scope access protection, and this other keyword would have module-scope access protection.

-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to be... unnatural."

"Bruno Medeiros" <daiphoenixNO@SPAMlycos.com> wrote in message news:drqlsa$17t6$1@digitaldaemon.com...
> I don't know, I don't recall being bugged by such problem.

Surely you jest!  You mean you've _never_ wanted two classes to be able to access each others' protected/private members, since making those members public would be a very bad thing?  I find that difficult to believe.

> How do other languages deal with this? Java and C# don't have a protection level like that, as the nearest they have to private (excluding private itself) is respectively, package and internal ('internal' being: accessible within the assembly). And I don't hear people complain about it. Wouldn't D's 'package' protection suffice for this?
>
> I really don't like when it (D) goes against what is common in the trio of
> disparate languages that is C++, Java and C#. Usually the things that are
> common among these three (and even among other languages) are the things
> that standard and/or well-done/well-tought. Remember in the "C++ vs Java
> vs Python vs Ruby" article the comment "Why does Ruby use rescue/ensure
> when the rest of the world has settled on try/catch/finally"?
> I think we should strive for consistency in the things that are standard
> amongst many languages, unless there is a good reason not to.

As far as I know (with my relatively limited knowledge of Java and C#), the protection schemes of Java and C# are fairly similar but they're both pretty different from C++'s.  There's no idea of friend classes in Java or C#, and there's no idea of a package in C++.  They've got different protection schemes because they take different approaches to program structure.  D takes a similar, yet still different, stance to program structure as Java and C#, so I don't see what's wrong with having different protection mechanisms.

> So again I ask, is there a good reason not to? Wouldn't D's package protection suffice for this? Don't Java and C# face this problem? (C# is even "worse" in that 'internal' is even less restrictive than 'package'.)

Well, what if you only want the members to be accessible to code in the same module?  package doesn't help you there.

> If even so you think we should have such a access protection level, why not just make a new keyword for it? Like 'restricted' or 'internal' (would not be the same as C#'s 'internal', yes) or something else. Thus we would have 'private' work as immediate-scope access protection, and this other keyword would have module-scope access protection.

I think that perhaps the system of protection attributes needs to be rethought in spots.  For example, if we really wanted to have a lot of control over protection, we could have the following (for class members):

module private - Completely private.  Nothing but the owning class (and nested classes ;)) may access it.  This is the default?

module protected - Accessible to owning class and any classes derived in the same module.

module public - Public to the entire module.  Inaccessible outside the module.

package protected - Accessible to owning class, and any classes derived from it in the same package (i.e. same directory).

package public - Public to the entire package (same directory). Inaccessible from other packages.

public - Anyone can access it.

Module-level members could only be declared module public (or maybe just "module"), package public (or just "package"), or public; they would be module by default.

This way, "private" and "protected" become class-only terms, and access is specified mainly by who can access it (just this module, this package, or anyone).  Of course, if this were to be enforced, the idea of "packages" in D would have to be a little more well-defined (as I think the entire module/package/import system is.. well, lacking).

"Walter Bright" <newshound@digitalmars.com> wrote in message news:drmfdg$1kcv$1@digitaldaemon.com...
> I belatedly thought of that after I posted that last message, and you're absolutely right. I'll fix it.
>

I'm not sure if this is caused by the exact same thing, but I'm sure it's related.

class A
{
 private int x;
}

class Wrapper
{
 static class B
 {
  void fork(A other)
  {
   writefln(other.x); // other.x is inaccessible
  }
 }
}

When defined in the same module.

It doesn't change if B is defined static or not.

Define B outside of Wrapper, and it works.

Jarrett Billingsley wrote:
> "Bruno Medeiros" <daiphoenixNO@SPAMlycos.com> wrote in message news:drqlsa$17t6$1@digitaldaemon.com...
>> I don't know, I don't recall being bugged by such problem.
> 
> Surely you jest!  You mean you've _never_ wanted two classes to be able to access each others' protected/private members, since making those members public would be a very bad thing?  I find that difficult to believe.
> 
Yes I've had that problem before of course. And I've made them public or package. You are saying that that is a very bad thing, but that is your opinion. For me, it is worse to not be able to make an entity (properly)private, as happens with D, than to make a module/friend entity be public/package/internal.

>> How do other languages deal with this? Java and C# don't have a protection level like that, as the nearest they have to private (excluding private itself) is respectively, package and internal ('internal' being: accessible within the assembly). And I don't hear people complain about it. Wouldn't D's 'package' protection suffice for this?
>>
>> I really don't like when it (D) goes against what is common in the trio of disparate languages that is C++, Java and C#. Usually the things that are common among these three (and even among other languages) are the things that standard and/or well-done/well-tought. Remember in the "C++ vs Java vs Python vs Ruby" article the comment "Why does Ruby use rescue/ensure when the rest of the world has settled on try/catch/finally"?
>> I think we should strive for consistency in the things that are standard amongst many languages, unless there is a good reason not to.
> 
> As far as I know (with my relatively limited knowledge of Java and C#), the protection schemes of Java and C# are fairly similar but they're both pretty different from C++'s.  There's no idea of friend classes in Java or C#, and there's no idea of a package in C++.  They've got different protection schemes because they take different approaches to program structure.  D takes a similar, yet still different, stance to program structure as Java and C#, so I don't see what's wrong with having different protection mechanisms.
> 
My quarrel here in this paragraph is not about having or not having a friend/module like access mechanism. It is just about the use of the 'private' keyword name. Java, C# and C++, have different protection schemes from each other, but not *that* different. And in particular, in ALL of them the access types 'public' and 'private' mean the EXACT same thing. In D it doesn't.

>> So again I ask, is there a good reason not to? Wouldn't D's package protection suffice for this? Don't Java and C# face this problem? (C# is even "worse" in that 'internal' is even less restrictive than 'package'.)
> 
> Well, what if you only want the members to be accessible to code in the same module?  package doesn't help you there.
> 
I would specify a module-wise access mechanism. I'm not against the existence of a module-wise access level, I just don't want 'private' to be that access level.
Also, you haven't answered my question. If the inexistence of a module/friend like access level is that bad, how do Java and C# deal with it?

>> If even so you think we should have such a access protection level, why not just make a new keyword for it? Like 'restricted' or 'internal' (would not be the same as C#'s 'internal', yes) or something else. Thus we would have 'private' work as immediate-scope access protection, and this other keyword would have module-scope access protection.
> 
> I think that perhaps the system of protection attributes needs to be rethought in spots.  For example, if we really wanted to have a lot of control over protection, we could have the following (for class members):
> 
> module private - Completely private.  Nothing but the owning class (and nested classes ;)) may access it.  This is the default?
> 
> module protected - Accessible to owning class and any classes derived in the same module.
> 
> module public - Public to the entire module.  Inaccessible outside the module.
> 
> package protected - Accessible to owning class, and any classes derived from it in the same package (i.e. same directory).
> 
> package public - Public to the entire package (same directory). Inaccessible from other packages.
> 
> public - Anyone can access it.
> 
> Module-level members could only be declared module public (or maybe just "module"), package public (or just "package"), or public; they would be module by default.
> 

We don't want that much verbosity|complexity|expressiveness.

-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to be... unnatural."