www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DIP22 - private symbol visibility

reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
 From his comments in the std.compress thread, Walter seems to 
believe that private symbols are not visible. This is not the 
case, and has never been the case. In current DMD, private 
symbols will name conflict with public symbols from other modules.

This has been discussed several times, and Dicebot has put 
together a proposal in DIP22.

http://wiki.dlang.org/DIP22

I want to open this up again because the previous thread died off 
with no conclusion. I urge Walter/Andrei to approve this if they 
are happy with it so that the compiler devs have the greenlight 
to put the fix in. It has been a longstanding issue with the 
language, and your approval is the only thing blocking it from 
finally being resolved.
Jun 04 2013
next sibling parent reply "Max Samukha" <maxsamukha gmail.com> writes:
On Tuesday, 4 June 2013 at 17:39:05 UTC, Peter Alexander wrote:
 http://wiki.dlang.org/DIP22

"I'd also throw in getting rid of the "protected" access attribute completely, as I've seen debate over that being a useless idea" How is that useless? Any non-trivial OOP code (http://qt-project.org/doc/qt-4.8/qabstractitemview.html#protected-functions) swarm with protected methods, and rightfully so. How would one restrict access to members that are not part of public interface but should be accessible to the derived classes?
Jun 04 2013
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 06/04/2013 08:10 PM, Max Samukha wrote:
 On Tuesday, 4 June 2013 at 17:39:05 UTC, Peter Alexander wrote:
 http://wiki.dlang.org/DIP22

"I'd also throw in getting rid of the "protected" access attribute completely, as I've seen debate over that being a useless idea" How is that useless? Any non-trivial OOP code (http://qt-project.org/doc/qt-4.8/qabstractitemview.html#protected-functions) swarm with protected methods, and rightfully so. How would one restrict access to members that are not part of public interface but should be accessible to the derived classes?

I don't think it is possible. protected methods are part of the public interface, since inheritance cannot be restricted selectively.
Jun 04 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 04 Jun 2013 14:10:32 -0400, Max Samukha <maxsamukha gmail.com>  
wrote:

 On Tuesday, 4 June 2013 at 17:39:05 UTC, Peter Alexander wrote:
 http://wiki.dlang.org/DIP22

"I'd also throw in getting rid of the "protected" access attribute completely, as I've seen debate over that being a useless idea" How is that useless? Any non-trivial OOP code (http://qt-project.org/doc/qt-4.8/qabstractitemview.html#protected-functions) swarm with protected methods, and rightfully so. How would one restrict access to members that are not part of public interface but should be accessible to the derived classes?

Looking at the original comment here: http://forum.dlang.org/post/kb86il$1u9v$1 digitalmars.com It looks like Jonathan raised the same point, but Walter never answered. Since protected access is actually ESSENTIAL in OOP (at least, some form of virtual non-public function access, private is not virtual, so it would be disastrous to remove protected), I am wondering whether Walter really meant "package", as that has very little utility. Care to answer, Walter? -Steve
Jun 04 2013
prev sibling next sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Tuesday, 4 June 2013 at 18:33:21 UTC, Steven Schveighoffer 
wrote:
 Since protected access is actually ESSENTIAL in OOP (at least, 
 some form of virtual non-public function access, private is not 
 virtual, so it would be disastrous to remove protected), I am 
 wondering whether Walter really meant "package", as that has 
 very little utility.

"package" may become quite useful once we have better package. It allows to have some local "utility" module used by specific package but not generic enough in global so that it won't cause name collision (after DIP22 is implemented, of course).
Jun 04 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 04 Jun 2013 15:13:30 -0400, Dicebot <m.strashun gmail.com> wrote:

 On Tuesday, 4 June 2013 at 18:33:21 UTC, Steven Schveighoffer wrote:
 Since protected access is actually ESSENTIAL in OOP (at least, some  
 form of virtual non-public function access, private is not virtual, so  
 it would be disastrous to remove protected), I am wondering whether  
 Walter really meant "package", as that has very little utility.

"package" may become quite useful once we have better package. It allows to have some local "utility" module used by specific package but not generic enough in global so that it won't cause name collision (after DIP22 is implemented, of course).

Sure, but I'm trying to read the comment in the context it was in. Certainly, if Daniel's patch to allow package imports is accepted, then package becomes almost essential for splitting up a module :) But at the time this comment was made, none of that was on the table. And removing protected would be disastrous. I can't fathom why he said protected should be removed. Which is why I hypothesized that he really meant package. But I'd rather just let Walter explain what he meant at this point... -Steve
Jun 04 2013
prev sibling next sibling parent Marco Leise <Marco.Leise gmx.de> writes:
Am Tue, 04 Jun 2013 20:10:32 +0200
schrieb "Max Samukha" <maxsamukha gmail.com>:

 On Tuesday, 4 June 2013 at 17:39:05 UTC, Peter Alexander wrote:
 http://wiki.dlang.org/DIP22

"I'd also throw in getting rid of the "protected" access attribute completely, as I've seen debate over that being a useless idea" How is that useless? Any non-trivial OOP code (http://qt-project.org/doc/qt-4.8/qabstractitemview.html#protected-functions) swarm with protected methods, and rightfully so. How would one restrict access to members that are not part of public interface but should be accessible to the derived classes?

On a different note, it could be disallowed on structs if it is allowed there, to avoid confusion about its effect there. -- Marco
Jun 04 2013
prev sibling next sibling parent "Max Samukha" <maxsamukha gmail.com> writes:
On Tuesday, 4 June 2013 at 18:33:21 UTC, Steven Schveighoffer 
wrote:

 Since protected access is actually ESSENTIAL in OOP (at least, 
 some form of virtual non-public function access, private is not 
 virtual, so it would be disastrous to remove protected), I am 
 wondering whether Walter really meant "package", as that has 
 very little utility.

 Care to answer, Walter?

 -Steve

'package' cannot possibly solve the problem because the protected members should be accessible outside of the defining package.
Jun 04 2013
prev sibling parent "Max Samukha" <maxsamukha gmail.com> writes:
On Tuesday, 4 June 2013 at 21:32:32 UTC, Timon Gehr wrote:
 On 06/04/2013 08:10 PM, Max Samukha wrote:
 On Tuesday, 4 June 2013 at 17:39:05 UTC, Peter Alexander wrote:
 http://wiki.dlang.org/DIP22

"I'd also throw in getting rid of the "protected" access attribute completely, as I've seen debate over that being a useless idea" How is that useless? Any non-trivial OOP code (http://qt-project.org/doc/qt-4.8/qabstractitemview.html#protected-functions) swarm with protected methods, and rightfully so. How would one restrict access to members that are not part of public interface but should be accessible to the derived classes?

I don't think it is possible. protected methods are part of the public interface, since inheritance cannot be restricted selectively.

I don't quite understand. Could you explain?
Jun 04 2013