www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Is it a bug that a parent class that access its own private members

reply bauss <jj_1337 live.dk> writes:
jesus that became a long title.

Anyway as the title says, is it a bug that a parent class that 
access its own private members from derived classes gets 
deprecation warning?

Scenario narrowed down:

// module foo;
class Foo
{
     private:
     bool _baz;

     public:
     final void foos(T : Foo)(string key, T[] values)
     {
       if (values && values.length)
       {
         foreach (child; values)
         {
           child._isChild = true;
         }
       }
     }
}

// module bar;
class Bar : Foo
{
}

The above in my case will give a deprecation warning that "_baz" 
isn't visible from "Bar".

Seems like a bug to me since I'm accessing "_baz" from "Foo" 
itself and not from "Bar" or is it by design that you can't do 
such thing.

I'm thinking it's because of my templated function perhaps?

I haven't decoupled it out of my project to make a separate 
compilation, I just want to clarify it's not a design thing 
first, because if it's by design then I don't want to spend more 
time on it than necessary.

If it's not by design then I'll narrow it down even more, to see 
if it's reproducable as above.

(I did not test the narrowed down version.)
Apr 07 2018
next sibling parent bauss <jj_1337 live.dk> writes:
On Saturday, 7 April 2018 at 20:14:49 UTC, bauss wrote:

         foreach (child; values)
         {
           child._isChild = true;
         }


I forgot: _isChild should be _baz in the narrowed down version.
Apr 07 2018
prev sibling next sibling parent reply user1234 <user1234 12.nl> writes:
On Saturday, 7 April 2018 at 20:14:49 UTC, bauss wrote:

 jesus that became a long title.

 Anyway as the title says, is it a bug that a parent class that 
 access its own private members from derived classes gets 
 deprecation warning?


If the import is selective no. (`import foo : Foo;`)
If the import is for the whole module i'd say yes. (`import foo;`)
Apr 07 2018
parent reply bauss <jj_1337 live.dk> writes:
On Saturday, 7 April 2018 at 20:34:57 UTC, user1234 wrote:

 On Saturday, 7 April 2018 at 20:14:49 UTC, bauss wrote:

 jesus that became a long title.

 Anyway as the title says, is it a bug that a parent class that 
 access its own private members from derived classes gets 
 deprecation warning?


 If the import is selective no. (`import foo : Foo;`)
 If the import is for the whole module i'd say yes. (`import 
 foo;`)


What do you mean?

The problem is that "Foo" cannot access "_baz" without 
deperecation warning, but "_baz" is a part of "Foo".
Apr 07 2018
next sibling parent bauss <jj_1337 live.dk> writes:
On Saturday, 7 April 2018 at 20:46:39 UTC, bauss wrote:

 The problem is that "Foo" cannot access "_baz" without 
 deperecation warning, but "_baz" is a part of "Foo".


I'm not trying to access "_baz" directly from "Bar" except for 
that I call the templated function that access "_baz", but that 
function is a part of "Foo"
Apr 07 2018
prev sibling parent reply user1234 <user1234 12.nl> writes:
On Saturday, 7 April 2018 at 20:46:39 UTC, bauss wrote:

 On Saturday, 7 April 2018 at 20:34:57 UTC, user1234 wrote:

 On Saturday, 7 April 2018 at 20:14:49 UTC, bauss wrote:

 jesus that became a long title.

 Anyway as the title says, is it a bug that a parent class 
 that access its own private members from derived classes gets 
 deprecation warning?


 If the import is selective no. (`import foo : Foo;`)
 If the import is for the whole module i'd say yes. (`import 
 foo;`)


 What do you mean?

 The problem is that "Foo" cannot access "_baz" without 
 deperecation warning, but "_baz" is a part of "Foo".


_baz is private and not protected. The deprecation was introduced 
because bug 314 broke the private protection.
Apr 08 2018
parent reply bauss <jj_1337 live.dk> writes:
On Sunday, 8 April 2018 at 10:48:19 UTC, user1234 wrote:

 On Saturday, 7 April 2018 at 20:46:39 UTC, bauss wrote:

 On Saturday, 7 April 2018 at 20:34:57 UTC, user1234 wrote:

 On Saturday, 7 April 2018 at 20:14:49 UTC, bauss wrote:

 jesus that became a long title.

 Anyway as the title says, is it a bug that a parent class 
 that access its own private members from derived classes 
 gets deprecation warning?


 If the import is selective no. (`import foo : Foo;`)
 If the import is for the whole module i'd say yes. (`import 
 foo;`)


 What do you mean?

 The problem is that "Foo" cannot access "_baz" without 
 deperecation warning, but "_baz" is a part of "Foo".


 _baz is private and not protected. The deprecation was 
 introduced because bug 314 broke the private protection.


I think it's better demonstrated like this, because to me the 
behavior makes no sense.

Especially since you can just cast "Bar" to "Foo" and then you're 
allowed to do it.

Since we're inside Foo then it shouldn't care whether "_baz" is 
private or not.

I could understand if the function was located within Bar, but 
it's not.

It's perfectly normal in other languages that supports classes to 
access private members of parent's as long as you're within the 
parent's encapsulation.

// a.d
module a;

class Foo
{
	private:
	bool _baz;
	
	public:
	void handleBar(T : Foo)(T[] foos)
	{
		foreach (child; foos)
		{
			child._baz = true; // Not ok.
			(cast(Foo)child)._baz = true; // Ok.
		}
	}
}

// b.d
module b;

import a;

class Bar : Foo
{
	
}

// main.d

module main;

import b;

void main()
{
	auto bars = [new Bar, new Bar];
	auto bar = new Bar;
	bar.handleBar(bars);
}
Apr 08 2018
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 08.04.2018 15:00, bauss wrote:

 
 It's perfectly normal in other languages that supports classes to access 
 private members of parent's as long as you're within the parent's 
 encapsulation.


That is not true. Use 'protected'.
Apr 08 2018
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 08.04.2018 16:36, Timon Gehr wrote:

 On 08.04.2018 15:00, bauss wrote:

 It's perfectly normal in other languages that supports classes to 
 access private members of parent's as long as you're within the 
 parent's encapsulation.


 
 That is not true. Use 'protected'.


Actually, I misunderstood your sentence.
This is definitely a bug.
Apr 08 2018
prev sibling next sibling parent reply kdevel <kdevel vogtner.de> writes:
On Sunday, 8 April 2018 at 13:00:02 UTC, bauss wrote:

[...]


 // a.d
 module a;

 class Foo
 {
 	private:
 	bool _baz;
 	
 	public:
 	void handleBar(T : Foo)(T[] foos)
 	{
 		foreach (child; foos)
 		{
 			child._baz = true; // Not ok.


replace this line with

    import std.stdio;
    __PRETTY_FUNCTION__.writeln;
    foos.writeln;

This writelns:

    void a.Foo.handleBar!(Bar).handleBar(Bar[] foos)
    [b.Bar, b.Bar]

So foos is actually an array of Bars. And there is no access from 
a Bar to the private elements of it's baseclass Foo.

What I am wondering about is why does the method template match 
in the first place?


 			(cast(Foo)child)._baz = true; // Ok.


You also may use the ternary conditional operator for that (SCNR).
Apr 08 2018
parent bauss <jj_1337 live.dk> writes:
On Sunday, 8 April 2018 at 14:45:34 UTC, kdevel wrote:

 On Sunday, 8 April 2018 at 13:00:02 UTC, bauss wrote:

 [...]


 // a.d
 module a;

 class Foo
 {
 	private:
 	bool _baz;
 	
 	public:
 	void handleBar(T : Foo)(T[] foos)
 	{
 		foreach (child; foos)
 		{
 			child._baz = true; // Not ok.


 replace this line with

    import std.stdio;
    __PRETTY_FUNCTION__.writeln;
    foos.writeln;

 This writelns:

    void a.Foo.handleBar!(Bar).handleBar(Bar[] foos)
    [b.Bar, b.Bar]

 So foos is actually an array of Bars. And there is no access 
 from a Bar to the private elements of it's baseclass Foo.


Yes, but we're in the module a and private is module level, so it 
should be accessible from the function regardless of whether it's 
Bar or not.
Apr 08 2018
prev sibling next sibling parent reply martin <martin mab-on.net> writes:
On Sunday, 8 April 2018 at 13:00:02 UTC, bauss wrote:

 I think it's better demonstrated like this, because to me the 
 behavior makes no sense.

 Especially since you can just cast "Bar" to "Foo" and then 
 you're allowed to do it.

 Since we're inside Foo then it shouldn't care whether "_baz" is 
 private or not.

 I could understand if the function was located within Bar, but 
 it's not.

 It's perfectly normal in other languages that supports classes 
 to access private members of parent's as long as you're within 
 the parent's encapsulation.

 // a.d
 module a;

 class Foo
 {
 	private:
 	bool _baz;
 	
 	public:
 	void handleBar(T : Foo)(T[] foos)
 	{
 		foreach (child; foos)
 		{
 			child._baz = true; // Not ok.
 			(cast(Foo)child)._baz = true; // Ok.
 		}
 	}
 }

 // b.d
 module b;

 import a;

 class Bar : Foo
 {
 	
 }

 // main.d

 module main;

 import b;

 void main()
 {
 	auto bars = [new Bar, new Bar];
 	auto bar = new Bar;
 	bar.handleBar(bars);
 }


Actually, this behaves as i would expect.
`_baz` is a private member of Foo (to be precise: it belongs to 
module `a`)
in handleBar(), you iterate `Bar[]` - which is in module `b`.
By casting it to Foo, you are accessing the wanted module (`a`) 
again.
Apr 09 2018
parent reply bauss <jj_1337 live.dk> writes:
On Monday, 9 April 2018 at 17:05:45 UTC, martin wrote:

 On Sunday, 8 April 2018 at 13:00:02 UTC, bauss wrote:

 I think it's better demonstrated like this, because to me the 
 behavior makes no sense.

 Especially since you can just cast "Bar" to "Foo" and then 
 you're allowed to do it.

 Since we're inside Foo then it shouldn't care whether "_baz" 
 is private or not.

 I could understand if the function was located within Bar, but 
 it's not.

 It's perfectly normal in other languages that supports classes 
 to access private members of parent's as long as you're within 
 the parent's encapsulation.

 // a.d
 module a;

 class Foo
 {
 	private:
 	bool _baz;
 	
 	public:
 	void handleBar(T : Foo)(T[] foos)
 	{
 		foreach (child; foos)
 		{
 			child._baz = true; // Not ok.
 			(cast(Foo)child)._baz = true; // Ok.
 		}
 	}
 }

 // b.d
 module b;

 import a;

 class Bar : Foo
 {
 	
 }

 // main.d

 module main;

 import b;

 void main()
 {
 	auto bars = [new Bar, new Bar];
 	auto bar = new Bar;
 	bar.handleBar(bars);
 }


 Actually, this behaves as i would expect.
 `_baz` is a private member of Foo (to be precise: it belongs to 
 module `a`)
 in handleBar(), you iterate `Bar[]` - which is in module `b`.
 By casting it to Foo, you are accessing the wanted module (`a`) 
 again.


but handleBar() is in a.
Apr 09 2018
parent reply martin <martin mab-on.net> writes:
On Monday, 9 April 2018 at 17:16:56 UTC, bauss wrote:

 On Monday, 9 April 2018 at 17:05:45 UTC, martin wrote:>>

 Actually, this behaves as i would expect.
 `_baz` is a private member of Foo (to be precise: it belongs 
 to module `a`)
 in handleBar(), you iterate `Bar[]` - which is in module `b`.
 By casting it to Foo, you are accessing the wanted module 
 (`a`) again.


 but handleBar() is in a.




`_baz` is a member of `module a : Foo` - `_baz`, as is 
`handleBar()`.
`protected` is the Access specifier you want.
If i understand you correctly, you want it to behave as  if 
`_baz` would be a member of `handleBar()`
Apr 11 2018
parent reply bauss <jj_1337 live.dk> writes:
On Wednesday, 11 April 2018 at 17:20:23 UTC, martin wrote:

 On Monday, 9 April 2018 at 17:16:56 UTC, bauss wrote:

 On Monday, 9 April 2018 at 17:05:45 UTC, martin wrote:>>

 Actually, this behaves as i would expect.
 `_baz` is a private member of Foo (to be precise: it belongs 
 to module `a`)
 in handleBar(), you iterate `Bar[]` - which is in module `b`.
 By casting it to Foo, you are accessing the wanted module 
 (`a`) again.


 but handleBar() is in a.




 `_baz` is a member of `module a : Foo` - `_baz`, as is 
 `handleBar()`.
 `protected` is the Access specifier you want.
 If i understand you correctly, you want it to behave as  if 
 `_baz` would be a member of `handleBar()`






It's a really common pattern with OOP.

public class Foo
{
	private string _baz;
	
	public void HandleBar(Bar bar)
	{
		bar._baz = "Hello";
	}
}

public class Bar : Foo
{
}

...

var bar = new Bar();
bar.HandleBar(bar);
Apr 11 2018
parent bauss <jj_1337 live.dk> writes:
On Wednesday, 11 April 2018 at 17:34:40 UTC, bauss wrote:

 On Wednesday, 11 April 2018 at 17:20:23 UTC, martin wrote:

 On Monday, 9 April 2018 at 17:16:56 UTC, bauss wrote:

 On Monday, 9 April 2018 at 17:05:45 UTC, martin wrote:>>

 Actually, this behaves as i would expect.
 `_baz` is a private member of Foo (to be precise: it belongs 
 to module `a`)
 in handleBar(), you iterate `Bar[]` - which is in module `b`.
 By casting it to Foo, you are accessing the wanted module 
 (`a`) again.


 but handleBar() is in a.




 `_baz` is a member of `module a : Foo` - `_baz`, as is 
 `handleBar()`.
 `protected` is the Access specifier you want.
 If i understand you correctly, you want it to behave as  if 
 `_baz` would be a member of `handleBar()`






 It's a really common pattern with OOP.

 public class Foo
 {
 	private string _baz;
 	
 	public void HandleBar(Bar bar)
 	{
 		bar._baz = "Hello";
 	}
 }

 public class Bar : Foo
 {
 }

 ...

 var bar = new Bar();
 bar.HandleBar(bar);


Also protected is not the access modifier I want.

I only want to set it through the parent class and it should only 
be used within the parent class.

But it's on each child passed to the parent class that it's set.

The children should NEVER touch the variable.
Apr 11 2018
prev sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Sunday, April 08, 2018 13:00:02 bauss via Digitalmars-d wrote:

 On Sunday, 8 April 2018 at 10:48:19 UTC, user1234 wrote:

 On Saturday, 7 April 2018 at 20:46:39 UTC, bauss wrote:

 On Saturday, 7 April 2018 at 20:34:57 UTC, user1234 wrote:

 On Saturday, 7 April 2018 at 20:14:49 UTC, bauss wrote:

 jesus that became a long title.

 Anyway as the title says, is it a bug that a parent class
 that access its own private members from derived classes
 gets deprecation warning?


 If the import is selective no. (`import foo : Foo;`)
 If the import is for the whole module i'd say yes. (`import
 foo;`)


 What do you mean?

 The problem is that "Foo" cannot access "_baz" without
 deperecation warning, but "_baz" is a part of "Foo".


 _baz is private and not protected. The deprecation was
 introduced because bug 314 broke the private protection.


 I think it's better demonstrated like this, because to me the
 behavior makes no sense.

 Especially since you can just cast "Bar" to "Foo" and then you're
 allowed to do it.

 Since we're inside Foo then it shouldn't care whether "_baz" is
 private or not.

 I could understand if the function was located within Bar, but
 it's not.

 It's perfectly normal in other languages that supports classes to
 access private members of parent's as long as you're within the
 parent's encapsulation.

 // a.d
 module a;

 class Foo
 {
   private:
   bool _baz;

   public:
   void handleBar(T : Foo)(T[] foos)
   {
       foreach (child; foos)
       {
           child._baz = true; // Not ok.
           (cast(Foo)child)._baz = true; // Ok.
       }
   }
 }

 // b.d
 module b;

 import a;

 class Bar : Foo
 {

 }

 // main.d

 module main;

 import b;

 void main()
 {
   auto bars = [new Bar, new Bar];
   auto bar = new Bar;
   bar.handleBar(bars);
 }


I don't know. It could be argued either way. I think that the logic as to
why

child._baz = true;

is not legal is because you're accessing it through a class reference that
does not have access to _baz, since it's private to the base class. Allowing
access to the base class member via a derived class reference arguably
violates private.

On the other hand, this is inside a member function of the base class, and
the base class has access to the private members - even if they're in an
object other than the current one. And by that logic, it should be legal to
access the base class member even though it's through a derived class
reference.

Usually, base classes don't handle any references for derived classes (they
may handle derived classes through base class references but not usually
through actual derived class references), and this sort of thing doesn't
come up. As such, I think that the obvious result would be the current
behavior regardless of whether that is actually the best behavior.

I suspect that this particular situation was never really thought through in
the implementation, but I don't know. And since I think that there are good
arguments in both directions, I really don't know whether the current
implementation is better or whether what you're trying to do should be
legal. Certainly, it seems like a valid enhancement request, though I have
no idea whether Walter would think that what you're trying to do should work
or not. I wouldn't be surprised either way.

- Jonathan M Davis
Apr 11 2018
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 11.04.2018 19:58, Jonathan M Davis wrote:

 I don't know. It could be argued either way.


Not really. bauss is right about this.
https://en.wikipedia.org/wiki/Liskov_substitution_principle
Apr 11 2018
prev sibling parent reply bauss <jj_1337 live.dk> writes:
On Wednesday, 11 April 2018 at 17:58:25 UTC, Jonathan M Davis 
wrote:

 On Sunday, April 08, 2018 13:00:02 bauss via Digitalmars-d 
 wrote:

 [...]


 I don't know. It could be argued either way. I think that the 
 logic as to why

 [...]


The thing is, it makes no sense why it shouldn't be legal since 
you can just cast to the base type, by that alone you're escaping 
the restriction that it's supposed to have.

And it really goes against that private is module level.

If it was module level then you should be able to access the 
member regardless of the reference to it.
Apr 11 2018
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 4/11/18 3:13 PM, bauss wrote:

 On Wednesday, 11 April 2018 at 17:58:25 UTC, Jonathan M Davis wrote:

 On Sunday, April 08, 2018 13:00:02 bauss via Digitalmars-d wrote:

 [...]


 I don't know. It could be argued either way. I think that the logic as 
 to why

 [...]


 
 The thing is, it makes no sense why it shouldn't be legal since you can 
 just cast to the base type, by that alone you're escaping the 
 restriction that it's supposed to have.
 
 And it really goes against that private is module level.
 
 If it was module level then you should be able to access the member 
 regardless of the reference to it.


Just going through old messages on the NG.

I filed a bug about a similar thing (calling private functions instead 
of using private variables), but it seemed to be agreed upon that this 
is expected behavior:

https://issues.dlang.org/show_bug.cgi?id=15897

You may find some more insight from reading that discussion. I don't 
agree with the conclusion, as it is very surprising behavior to me.

-Steve
Jun 11 2018
next sibling parent bauss <jj_1337 live.dk> writes:
On Monday, 11 June 2018 at 15:41:57 UTC, Steven Schveighoffer 
wrote:

 On 4/11/18 3:13 PM, bauss wrote:

 On Wednesday, 11 April 2018 at 17:58:25 UTC, Jonathan M Davis 
 wrote:

 On Sunday, April 08, 2018 13:00:02 bauss via Digitalmars-d 
 wrote:

 [...]


 I don't know. It could be argued either way. I think that the 
 logic as to why

 [...]


 
 The thing is, it makes no sense why it shouldn't be legal 
 since you can just cast to the base type, by that alone you're 
 escaping the restriction that it's supposed to have.
 
 And it really goes against that private is module level.
 
 If it was module level then you should be able to access the 
 member regardless of the reference to it.


 Just going through old messages on the NG.

 I filed a bug about a similar thing (calling private functions 
 instead of using private variables), but it seemed to be agreed 
 upon that this is expected behavior:

 https://issues.dlang.org/show_bug.cgi?id=15897

 You may find some more insight from reading that discussion. I 
 don't agree with the conclusion, as it is very surprising 
 behavior to me.

 -Steve


It goes against everything OOP and it goes against D's own 
private.
Jun 12 2018
prev sibling parent reply Elie Morisse <syniurge gmail.com> writes:
On Monday, 11 June 2018 at 15:41:57 UTC, Steven Schveighoffer 
wrote:

 I filed a bug about a similar thing (calling private functions 
 instead of using private variables), but it seemed to be agreed 
 upon that this is expected behavior:

 https://issues.dlang.org/show_bug.cgi?id=15897

 You may find some more insight from reading that discussion. I 
 don't agree with the conclusion, as it is very surprising 
 behavior to me.

 -Steve


Not the same, bauss' case is a template method that wouldn't get 
the depreciation warning if it wasn't templated. Template 
instances not always having the same access privileges as their 
template declaration's is definitely a bug.
Aug 30 2018
parent Elie Morisse <syniurge gmail.com> writes:
On Thursday, 30 August 2018 at 12:18:10 UTC, Elie Morisse wrote:

 On Monday, 11 June 2018 at 15:41:57 UTC, Steven Schveighoffer 
 wrote:

 I filed a bug about a similar thing (calling private functions 
 instead of using private variables), but it seemed to be 
 agreed upon that this is expected behavior:

 https://issues.dlang.org/show_bug.cgi?id=15897

 You may find some more insight from reading that discussion. I 
 don't agree with the conclusion, as it is very surprising 
 behavior to me.

 -Steve


 Not the same, bauss' case is a template method that wouldn't 
 get the depreciation warning if it wasn't templated. Template 
 instances not always having the same access privileges as their 
 template declaration's is definitely a bug.


Or actually since I didn't test the code it's more likely just 
due to T being Bar, in which case there's no reason to make the 
cast to Foo mandatory since Foo's field get accessed from Foo's 
method.
Aug 30 2018
prev sibling next sibling parent Tony <tonytdominguez aol.com> writes:
On Saturday, 7 April 2018 at 20:14:49 UTC, bauss wrote:

 The above in my case will give a deprecation warning that 
 "_baz" isn't visible from "Bar".

 Seems like a bug to me since I'm accessing "_baz" from "Foo" 
 itself and not from "Bar" or is it by design that you can't do 
 such thing.


I would say that you are accessing it from Bar. Or maybe that 
should be "via Bar". You are in Foo, but with a reference to a 
Bar instance. And trying to get to the _baz that is in that Bar 
instance. But your design doesn't allow (or at least I would have 
thought it was an error, not warning) or want Bar objects to be 
able to access _baz.
Apr 08 2018
prev sibling parent nkm1 <t4nk074 openmailbox.org> writes:
On Saturday, 7 April 2018 at 20:14:49 UTC, bauss wrote:

 jesus that became a long title.

 Anyway as the title says, is it a bug that a parent class that 
 access its own private members from derived classes gets 
 deprecation warning?

 Scenario narrowed down:

 // module foo;
 class Foo
 {
     private:
     bool _baz;

     public:
     final void foos(T : Foo)(string key, T[] values)
     {
       if (values && values.length)
       {
         foreach (child; values)
         {
           child._isChild = true;
         }
       }
     }
 }

 // module bar;
 class Bar : Foo
 {
 }

 The above in my case will give a deprecation warning that 
 "_baz" isn't visible from "Bar".


Well, template has nothing to do with it. Also, private members 
in D are private to the module, not to the class. Here's a 
reduced example:

--- foo.d ---
import bar;

class Foo
{
     private bool baz;
}

void test(Bar b)
{
     b.baz = true;
}

--- bar.d ---
import foo;

class Bar : Foo {}

void main()
{
     test(new Bar);
}

https://wiki.dlang.org/DIP22 mentions something called "look-up 
origin"; the meaning of that term is unclear to me...
Apr 08 2018