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

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

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

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

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

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

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

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

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

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