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