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?


 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. 
 
 



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?
 


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


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


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

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 

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 

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' 

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.



 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 

 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.





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 

mechanisms.


 So again I ask, is there a good reason not to? Wouldn't D's package 

 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 

 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.
 


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.



 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 

 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.


 



 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 

 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 

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 

 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 

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 

 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