Jump to page: 1 2 3
Thread overview
Is it a bug that a parent class that access its own private members from derived classes gets deprecation warning?
Apr 07, 2018
bauss
Apr 07, 2018
bauss
Apr 07, 2018
user1234
Apr 07, 2018
bauss
Apr 07, 2018
bauss
Apr 08, 2018
user1234
Apr 08, 2018
bauss
Apr 08, 2018
Timon Gehr
Apr 08, 2018
Timon Gehr
Apr 08, 2018
kdevel
Apr 08, 2018
bauss
Apr 09, 2018
martin
Apr 09, 2018
bauss
Apr 11, 2018
martin
Apr 11, 2018
bauss
Apr 11, 2018
bauss
Apr 11, 2018
Jonathan M Davis
Apr 11, 2018
Timon Gehr
Apr 11, 2018
bauss
Jun 12, 2018
bauss
Aug 30, 2018
Elie Morisse
Aug 30, 2018
Elie Morisse
Apr 08, 2018
Tony
Apr 08, 2018
nkm1
April 07, 2018
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.)
April 07, 2018
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.
April 07, 2018
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;`)


April 07, 2018
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".
April 07, 2018
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"
April 08, 2018
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.
April 08, 2018
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.
April 08, 2018
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);
}

April 08, 2018
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'.
April 08, 2018
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).

« First   ‹ Prev
1 2 3