www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - Oh for christ's sake

reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
class A
{
 this()
 {
  b = new B();
  b.x = 5; // illegal
 }

 class B
 {
  protected int x;
 }

 B b;
}

FIX THIS.

I am tired of running into this constantly.  Most likely fix: in access.c, 
in AggregateDeclaration::isFriendOf(), add in the lines

if (cd && toParent() == cd)
{
#if LOG
printf("\this is nested in cd\n");
#endif
return 1;
}

I don't know if that'd work for multiply-nested classes, but it's a start. 
The other possibility would be to check, instead if if they are declared in 
the same scope (with the toParent() == cd->toParent()), if they truly are in 
the same module.

Currently, the relationship between nested and outer classes is only 
one-way; that is, nested classes can access outer classes' 
private/protected/package members, but not the other way around. 
Jan 30 2006
next sibling parent reply John Reimer <terminal.node gmail.com> writes:
Oh? And why not for Buddha's Sake?

Seriously... I can't figure out why people like to profane the Christian 
deity to express their frustrations.  Social programming must be the 
reason people do this, I guess.  It's sad...

... and very annoying.  There was, at one point, a gentleman's agreement 
to use "Bob" in such circumstances where one was absolutely unable to 
maintain self-control -- it was actually humorous and considerate at the 
same time.  It's safer too... better to belittle the corporeal than the 
celestial.

-JJR


Jarrett Billingsley wrote:
 class A
 {
  this()
  {
   b = new B();
   b.x = 5; // illegal
  }
 
  class B
  {
   protected int x;
  }
 
  B b;
 }
 
 FIX THIS.
 
 I am tired of running into this constantly.  Most likely fix: in access.c, 
 in AggregateDeclaration::isFriendOf(), add in the lines
 
 if (cd && toParent() == cd)
 {
 #if LOG
 printf("\this is nested in cd\n");
 #endif
 return 1;
 }
 
 I don't know if that'd work for multiply-nested classes, but it's a start. 
 The other possibility would be to check, instead if if they are declared in 
 the same scope (with the toParent() == cd->toParent()), if they truly are in 
 the same module.
 
 Currently, the relationship between nested and outer classes is only 
 one-way; that is, nested classes can access outer classes' 
 private/protected/package members, but not the other way around. 
 
 

Jan 30 2006
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"John Reimer" <terminal.node gmail.com> wrote in message 
news:drm7o8$1556$1 digitaldaemon.com...
 Oh? And why not for Buddha's Sake?

And you thought it was necessary to bring this up.. why? Maybe, instead of everyone trying to be PC all the time, people shouldn't get so damn worked up over something that's become part of the public lexicon. If you're offended, look somewhere else.
Jan 30 2006
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
news:drm9am$182c$1 digitaldaemon.com...
 "John Reimer" <terminal.node gmail.com> wrote in message 
 news:drm7o8$1556$1 digitaldaemon.com...
 Oh? And why not for Buddha's Sake?

And you thought it was necessary to bring this up.. why? Maybe, instead of everyone trying to be PC all the time, people shouldn't get so damn worked up over something that's become part of the public lexicon. If you're offended, look somewhere else.

Sorry. This isn't the place to bring this up. I'm frustrated because I've reported this damned bug umpteen times and it hasn't even gotten recognition from Walter that it's a bug. And the only thing that seems to be happening with D right now is some frilly template metaprogramming fixes.
Jan 30 2006
next sibling parent John Reimer <terminal.node gmail.com> writes:
Jarrett Billingsley wrote:
 "Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
 news:drm9am$182c$1 digitaldaemon.com...
 "John Reimer" <terminal.node gmail.com> wrote in message 
 news:drm7o8$1556$1 digitaldaemon.com...
 Oh? And why not for Buddha's Sake?

Maybe, instead of everyone trying to be PC all the time, people shouldn't get so damn worked up over something that's become part of the public lexicon. If you're offended, look somewhere else.

Sorry. This isn't the place to bring this up. I'm frustrated because I've reported this damned bug umpteen times and it hasn't even gotten recognition from Walter that it's a bug. And the only thing that seems to be happening with D right now is some frilly template metaprogramming fixes.

Chances are the bug will get the attention it needs as side affect of this thread. :P If it doesn't, all I can say is "wow!" I was indeed offended by the title, such that I cared little about what the content of your post (and I'm rarely offended by posts in the D groups). There may never be an "appropriate" place to bring this up where people's feelings are concerned, therefore I believed this was as appropriate a spot as it gets. PC'ness has nothing to do with this. I'm not afraid of being politically incorrect where the situation calls for it as, I think, most people here have noticed by now. If this group believes every word represented in the public lexicon is fair game, then perhaps I am in the wrong place; and I will indeed move elsewhere if it comes to that -- have no fears -- rather than pretend to be the local thread police. But, for your sake, I hope your bug is fixed in an upcoming release. Cheers, JJR
Jan 30 2006
prev sibling parent Dave <Dave_member pathlink.com> writes:
In article <drm9m9$190j$1 digitaldaemon.com>, Jarrett Billingsley says...
from Walter that it's a bug.  And the only thing that seems to be happening 
with D right now is some frilly template metaprogramming fixes. 

These are good for D, and what's good for D is good for you <g> - Dave
Jan 31 2006
prev sibling next sibling parent reply Carlos Santander <csantander619 gmail.com> writes:
Jarrett Billingsley escribió:
 class A
 {
  this()
  {
   b = new B();
   b.x = 5; // illegal
  }
 
  class B
  {
   protected int x;
  }
 
  B b;
 }
 

Unless you meant "private", I'm not sure this should be a bug. "protected" means it's visible to sub-classes, and A is not a sub-class of B, so I think it makes sense. -- Carlos Santander Bernal
Jan 30 2006
next sibling parent reply anon <anon_member pathlink.com> writes:
http://bibleresources.bible.com/passagesearchresults.php?passage1=Exodus+20:7&version=31
Jan 30 2006
parent Derek Parnell <derek psych.ward> writes:
On Tue, 31 Jan 2006 00:38:16 +0000 (UTC), anon wrote:

 http://bibleresources.bible.com/passagesearchresults.php?passage1=Exodus+20:7&version=31

So if 'christ' is not the name of one's God, or the expression is not a misuse of the name, then its okay to use this expression, right? Also I guess that the Exodus passage was specifically referring to YHWH and not the Jewish messiah. But seriously, we should be a bit more careful in our use of words because some expressions really do piss some people off. And on the other hand, one ought to make some allowances for cultural differences, especially in such an international and diverse forum. In general, everyone should cut everyone else some slack, okay? -- Derek (skype: derek.j.parnell) Melbourne, Australia "Down with mediocracy!" 31/01/2006 11:57:57 AM
Jan 30 2006
prev sibling parent reply John Reimer <terminal.node gmail.com> writes:
Carlos Santander wrote:
 Jarrett Billingsley escribió:
 class A
 {
  this()
  {
   b = new B();
   b.x = 5; // illegal
  }

  class B
  {
   protected int x;
  }

  B b;
 }

Unless you meant "private", I'm not sure this should be a bug. "protected" means it's visible to sub-classes, and A is not a sub-class of B, so I think it makes sense.

Isn't it the case in D, that classes of the same module have access to each other's members, private, or protected. For example, this works:
 module test;
 
 class B
 {
 	protected int b;	// this compiles
 	// private int b;	// this also compiles
 }
 
 class A
 {
 	this() 
 	{ 
 		bb = new B;
 		bb.b = 0; 
 	}
 	
 	B bb;
 }
 
 void main()
 {
 	A a = new A;
 }

So why doesn't this work with a nested class? I assume the answer relates somewhat similarly to scope rules? I must admit it seems strange. Does C++ allow nested classes? If not, then these rules pertaining to D cannot be compared to C++ treatment of the case; and this matter should be further investigated. If so, then, I guess we are stuck with Walter's opinion on the matter because he almost always bows to C++'s operation in such matters: if C++ does it that way, then D must follow suite. -JJR
Jan 30 2006
parent Carlos Santander <Carlos_member pathlink.com> writes:
In article <drmers$1jti$1 digitaldaemon.com>, John Reimer says...
Carlos Santander wrote:
 Jarrett Billingsley escribió:
 class A
 {
  this()
  {
   b = new B();
   b.x = 5; // illegal
  }

  class B
  {
   protected int x;
  }

  B b;
 }

Unless you meant "private", I'm not sure this should be a bug. "protected" means it's visible to sub-classes, and A is not a sub-class of B, so I think it makes sense.

Isn't it the case in D, that classes of the same module have access to each other's members, private, or protected. For example, this works:
 module test;
 
 class B
 {
 	protected int b;	// this compiles
 	// private int b;	// this also compiles
 }
 
 class A
 {
 	this() 
 	{ 
 		bb = new B;
 		bb.b = 0; 
 	}
 	
 	B bb;
 }
 
 void main()
 {
 	A a = new A;
 }

So why doesn't this work with a nested class? I assume the answer relates somewhat similarly to scope rules? I must admit it seems strange. Does C++ allow nested classes? If not, then these rules pertaining to D cannot be compared to C++ treatment of the case; and this matter should be further investigated. If so, then, I guess we are stuck with Walter's opinion on the matter because he almost always bows to C++'s operation in such matters: if C++ does it that way, then D must follow suite. -JJR

I checked the docs, and you're right. My mistake. -- Carlos Santander Bernal
Jan 31 2006
prev sibling next sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"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.
Jan 30 2006
next sibling parent reply "Chris Miller" <chris dprogramming.com> writes:
On Mon, 30 Jan 2006 19:52:47 -0500, Walter Bright  
<newshound digitalmars.com> 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.

It's the same error if x is private. It's an issue because of module friendship; things in the same module should be completely accessible. I run into this issue and end up making things public just to work around it.
Jan 30 2006
next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Chris Miller" <chris dprogramming.com> wrote in message 
news:op.s37xwrf4po9bzi moe...
 On Mon, 30 Jan 2006 19:52:47 -0500, Walter Bright 
 <newshound digitalmars.com> wrote:
 First I want to ask why is B.x given protected?


Thank you, so much, for replying to this, Walter. B.x is made protected (or private, or package) for the same reason any member is - so that other modules cannot access that data. I suppose in this particular instance, private would make more sense since nothing derives from B, but the problem is the same for any protection attribute other than public.
 It's the same error if x is private. It's an issue because of module 
 friendship; things in the same module should be completely accessible. I 
 run into this issue and end up making things public just to work around 
 it.

Exactly my point.
Jan 30 2006
prev sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Chris Miller" <chris dprogramming.com> wrote in message 
news:op.s37xwrf4po9bzi moe...
 It's the same error if x is private. It's an issue because of module 
 friendship; things in the same module should be completely accessible. I 
 run into this issue and end up making things public just to work around 
 it.

I belatedly thought of that after I posted that last message, and you're absolutely right. I'll fix it.
Jan 30 2006
next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"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.

Oh score. :)
Jan 30 2006
prev sibling next sibling parent Dave <Dave_member pathlink.com> writes:
In article <drmfdg$1kcv$1 digitaldaemon.com>, Walter Bright says...
"Chris Miller" <chris dprogramming.com> wrote in message 
news:op.s37xwrf4po9bzi moe...
 It's the same error if x is private. It's an issue because of module 
 friendship; things in the same module should be completely accessible. I 
 run into this issue and end up making things public just to work around 
 it.

I belatedly thought of that after I posted that last message, and you're absolutely right. I'll fix it.

What about this? class C(T) { private T i; // or protected or package } void main() { C!(int) c = new C!(int); // class t4.C!(int).C member i is not accessible c.i = 10; } Thanks, - Dave
Jan 31 2006
prev sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"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.
Feb 07 2006
parent reply Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jarrett Billingsley schrieb am 2006-02-08:
 "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.

Added to DStress as http://dstress.kuehne.cn/run/p/private_11_A.d http://dstress.kuehne.cn/run/p/private_11_B.d http://dstress.kuehne.cn/run/p/private_11_C.d Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFD7vCa3w+/yD4P9tIRApFXAJ0fsYh0epjGD6ozeJIvF5fXlTNxVgCguSR+ iALsB2W+SG7Bdq20/uxZTTw= =GOAs -----END PGP SIGNATURE-----
Feb 12 2006
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Thomas Kuehne" <thomas-dloop kuehne.cn> wrote in message 
news:qt73c3-4vs.ln1 birke.kuehne.cn...
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1

 Jarrett Billingsley schrieb am 2006-02-08:
 "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.

Added to DStress as http://dstress.kuehne.cn/run/p/private_11_A.d http://dstress.kuehne.cn/run/p/private_11_B.d http://dstress.kuehne.cn/run/p/private_11_C.d Thomas

Oh -- looks like 0.146 has fixed this, too. :)
Feb 12 2006
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
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? -- Derek (skype: derek.j.parnell) Melbourne, Australia "Down with mediocracy!" 31/01/2006 12:31:23 PM
Jan 30 2006
parent reply Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
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?

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."
Jan 31 2006
next sibling parent reply Derek Parnell <derek psych.ward> writes:
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?


(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
Jan 31 2006
parent Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
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?

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."
Feb 01 2006
prev sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"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.
Jan 31 2006
next sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"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.)
Jan 31 2006
parent Roberto Mariottini <Roberto_member pathlink.com> writes:
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
Feb 01 2006
prev sibling parent reply Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
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."
Feb 01 2006
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"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).
Feb 01 2006
parent Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
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.

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.

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.

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."
Feb 08 2006
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 30 Jan 2006 17:57:26 -0500, Jarrett Billingsley wrote:

 class A
 {
  this()
  {
   b = new B();
   b.x = 5; // illegal
  }
 
  class B
  {
   protected int x;
  }
 
  B b;
 }
 

I would not have thought this would have worked anyhow, but the way I routinely code this type of access is ... class A { this() { b = new B(); b.x = 5; // okay now. } class B { private int _x; void x(int q) { _x = q; } } B b; } In other words, I trade off runtime performance for access safety and control. -- Derek (skype: derek.j.parnell) Melbourne, Australia "Down with mediocracy!" 31/01/2006 12:20:21 PM
Jan 30 2006
parent Dave <Dave_member pathlink.com> writes:
In article <18fui87bms5nz.pxols0owa43g.dlg 40tude.net>, Derek Parnell says...
On Mon, 30 Jan 2006 17:57:26 -0500, Jarrett Billingsley wrote:

 class A
 {
  this()
  {
   b = new B();
   b.x = 5; // illegal
  }
 
  class B
  {
   protected int x;
  }
 
  B b;
 }
 

I would not have thought this would have worked anyhow, but the way I routinely code this type of access is ... class A { this() { b = new B(); b.x = 5; // okay now. } class B { private int _x; void x(int q) { _x = q; } } B b; } In other words, I trade off runtime performance for access safety and control.

If you made class B (or B.x()) final you wouldn't have to trade the runtime performance either. You can still inherit A w/o any prohibitions because nested classes like B are 'final' by definition (I wonder if inner classes like this should just be auto-final anyhow?). I tried it and the results are the same using the accessor functions or direct, and A can be inherited. Nonetheless, I tend to agree w/ the OP complaint though, because the different access rules for nested classes seems confusing given the access rules for modules. class A { this() { b = new B(); for(int i = 0; i < 100_000_000; i++) { if(i % 2 == 0) b.x = b.x + 5; // okay now. // b._x = b._x + 5; // okay now. else b.x = b.x - 5; // b._x = b._x - 5; } } final class B { private int _x; // int _x; int x() { return _x; } int x(int q) { _x = q; return q; } } B b; } class C : A {} import std.stdio; void main() { C c = new C; writefln(c.b.x); }
-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
31/01/2006 12:20:21 PM

Jan 31 2006