www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Shouldn't this be legal? (scope issue)

reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
[module1.d]

class A
{
 protected int foo;
}

[test.d]

import module1;

class B : A
{
 public int x()
 {
  return foo; // Can return own foo..
 }

 public int y(B b)
 {
  return b.foo; // Can return another B's foo..
 }

 public int z(A a)
 {
  return a.foo; // Can't return an A's foo?  Member inaccessible
 }
}

void main()
{
 A a=new A;
 B b1=new B;
 B b2=new B;
 b1.x();
 b1.y(b2);
 b1.z(a);
}


Member functions of B can access B's own foo, and the foos of other Bs, but 
not As' foos.  That seems odd.  Try changing .z() to:

 public int z(B b)
 {
  A a=cast(A) b;
  return a.foo;
 }

It'll also fail.  If foo is a member of A, and B is an A, why can't B access 
all public and protected members of As? 
Aug 20 2005
parent reply "Walter" <newshound digitalmars.com> writes:
The compiler is behaving correctly. Returning foo through an 'a' is not
going through the 'protected' path to get to foo.
Aug 20 2005
parent reply Burton Radons <burton-radons smocky.com> writes:
Walter wrote:
 The compiler is behaving correctly. Returning foo through an 'a' is not
 going through the 'protected' path to get to foo.

I can see that that's the way it works in C++, but it definitely doesn't feel right and it introduces a lot of meaning to what should be a simple property: a protected declaration is visible in this scope, in the scope of the containing module, and in the scope of inheriting objects. In fact, that is exactly what is in the D specification: "Protected means that only members of the enclosing class or any classes derived from that class, or members and functions in the same module as the enclosing class, can access the member. Protected module members are illegal." Instead, the C++ definition is that a protected declaration is visible in this scope, in the scope of the containing module, and when accessed in an inheriting object through references to that object only. Is this defensible? It just seems needlessly convoluted.
Aug 21 2005
next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Burton Radons" <burton-radons smocky.com> wrote in message 
news:de9g27$cs0$1 digitaldaemon.com...
 Walter wrote:
 The compiler is behaving correctly. Returning foo through an 'a' is not
 going through the 'protected' path to get to foo.

I can see that that's the way it works in C++, but it definitely doesn't feel right and it introduces a lot of meaning to what should be a simple property: a protected declaration is visible in this scope, in the scope of the containing module, and in the scope of inheriting objects. In fact, that is exactly what is in the D specification: "Protected means that only members of the enclosing class or any classes derived from that class, or members and functions in the same module as the enclosing class, can access the member. Protected module members are illegal." Instead, the C++ definition is that a protected declaration is visible in this scope, in the scope of the containing module, and when accessed in an inheriting object through references to that object only. Is this defensible? It just seems needlessly convoluted.

I definitely second this. The main problem I'm having is I have a hierarchy of objects. They all derive from the base class "A". Each instance of these objects has a parent A reference. I want to access a protected member of the parent object through a derived class's method, but I can't, even though the derived class inherits from A and can access its own protected members that come from A. It seems like a very arbitrary restriction.
Aug 21 2005
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Burton Radons" <burton-radons smocky.com> wrote in message
news:de9g27$cs0$1 digitaldaemon.com...
 Walter wrote:
 The compiler is behaving correctly. Returning foo through an 'a' is not
 going through the 'protected' path to get to foo.

I can see that that's the way it works in C++, but it definitely doesn't feel right and it introduces a lot of meaning to what should be a simple property: a protected declaration is visible in this scope, in the scope of the containing module, and in the scope of inheriting objects.

You're right in that it is the way it works in C++. But in all my years of working with C++, reading praises for it and diatribes against it, it has never come up that this mechanism is wrong. This makes me very reluctant to try changing it, I think experience suggests C++ got it right.
Aug 21 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Sun, 21 Aug 2005 12:00:22 -0700, Walter wrote:

 "Burton Radons" <burton-radons smocky.com> wrote in message
 news:de9g27$cs0$1 digitaldaemon.com...
 Walter wrote:
 The compiler is behaving correctly. Returning foo through an 'a' is not
 going through the 'protected' path to get to foo.

I can see that that's the way it works in C++, but it definitely doesn't feel right and it introduces a lot of meaning to what should be a simple property: a protected declaration is visible in this scope, in the scope of the containing module, and in the scope of inheriting objects.

You're right in that it is the way it works in C++. But in all my years of working with C++, reading praises for it and diatribes against it, it has never come up that this mechanism is wrong. This makes me very reluctant to try changing it, I think experience suggests C++ got it right.

Walter, how can these people solve the problem that they have? Jarrett Billingsley writes:
The main problem I'm having is I have a hierarchy 
of objects.  They all derive from the base class "A".  Each instance of 
these objects has a parent A reference.  I want to access a protected member 
of the parent object through a derived class's method, but I can't, even 
though the derived class inherits from A and can access its own protected 
members that come from A.

-- Derek Parnell Melbourne, Australia 22/08/2005 7:05:00 AM
Aug 21 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message
news:fi02524fyodu$.w0x6l8s2czgj.dlg 40tude.net...
 Walter, how can these people solve the problem that they have?

1) make it public 2) write a member function proxy to access it 3) put the class definitions that access it in the same module as the base
Aug 21 2005
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:deb4l8$1sp8$1 digitaldaemon.com...
 1) make it public

Errm if it were a member that I didn't mind having it as public, I wouldn't have this problem in the first place! It's protected for a reason - I don't want classes other than itself and derived classes accessing the member.
 2) write a member function proxy to access it

I'd have to make it a public function, which would again defeat the purpose of making the member protected.
 3) put the class definitions that access it in the same module as the base

Dumb, dumb, dumb. Why not just lift the restriction? Is there any really compelling reason?
Aug 21 2005