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
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
next sibling parent reply "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
next sibling parent reply "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
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 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 next sibling parent reply 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
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
prev 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