www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Fixing module-scope private

reply "mist" <none none.none> writes:
There was discussion recently about unpleasant name conflict 
possible with private module symbols. I have just encountered a 
sarcastically false statement on dlang.org : "Private module 
members are equivalent to static declarations in C programs."

Made me sad and wondering: was there any DIP after that thread or 
it has ended, as it often happens, with a decision to "plan 
carefully"? In latter case I may try to write one.
Jan 26 2013
next sibling parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Saturday, 26 January 2013 at 22:23:05 UTC, mist wrote:

 Made me sad and wondering: was there any DIP after that thread 
 or it has ended, as it often happens, with a decision to "plan 
 carefully"?


I *think* Walter is still against changing it, on the grounds 
that it would make module-level private different from any other 
type of private.
Jan 26 2013
next sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Saturday, 26 January 2013 at 23:13:02 UTC, Peter Alexander 
wrote:

 I *think* Walter is still against changing it, on the grounds 
 that it would make module-level private different from any 
 other type of private.


Well, I thought it was an agreement that we exactly lack 
currently way to do C global static or C++ unnamed namespace 
behavior.

No opinion currently if this should be "private" or anything but 
statement from dlang.org I have cited is terribly wrong currently 
and something needs to be done about it.
Jan 26 2013
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/26/13 6:13 PM, Peter Alexander wrote:

 On Saturday, 26 January 2013 at 22:23:05 UTC, mist wrote:

 Made me sad and wondering: was there any DIP after that thread or it
 has ended, as it often happens, with a decision to "plan carefully"?


 I *think* Walter is still against changing it, on the grounds that it
 would make module-level private different from any other type of private.


Walter and I believe it is necessary to define module private in a way 
that makes the symbol impossible to leak. Work on a detailed DIP would 
be definitely welcome. Walter enumerated a few concerns that the DIP 
should address in a message. What was the title of the past discussion?

Andrei
Jan 27 2013
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 01/27/2013 01:25 PM, Andrei Alexandrescu wrote:

 On 1/26/13 6:13 PM, Peter Alexander wrote:

 On Saturday, 26 January 2013 at 22:23:05 UTC, mist wrote:

 Made me sad and wondering: was there any DIP after that thread or it
 has ended, as it often happens, with a decision to "plan carefully"?


 I *think* Walter is still against changing it, on the grounds that it
 would make module-level private different from any other type of private.


 Walter and I believe it is necessary to define module private in a way
 that makes the symbol impossible to leak. Work on a detailed DIP would
 be definitely welcome. Walter enumerated a few concerns that the DIP
 should address in a message. What was the title of the past discussion?

 Andrei


http://forum.dlang.org/post/kb86il$1u9v$1 digitalmars.com
Jan 27 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/27/13 8:27 AM, Timon Gehr wrote:

 On 01/27/2013 01:25 PM, Andrei Alexandrescu wrote:

 On 1/26/13 6:13 PM, Peter Alexander wrote:

 On Saturday, 26 January 2013 at 22:23:05 UTC, mist wrote:

 Made me sad and wondering: was there any DIP after that thread or it
 has ended, as it often happens, with a decision to "plan carefully"?


 I *think* Walter is still against changing it, on the grounds that it
 would make module-level private different from any other type of
 private.


 Walter and I believe it is necessary to define module private in a way
 that makes the symbol impossible to leak. Work on a detailed DIP would
 be definitely welcome. Walter enumerated a few concerns that the DIP
 should address in a message. What was the title of the past discussion?

 Andrei


 http://forum.dlang.org/post/kb86il$1u9v$1 digitalmars.com


Thanks. That's the one! Looking forward to seeing a DIP.

Andrei
Jan 27 2013
prev sibling parent "Dicebot" <m.strashun gmail.com> writes:
As no one seems to be working on this I may try to resurrect all 
the info from previous topic and combine into a DIP matching 
Walters request. Added this to personal TODO list.

Thanks.
Jan 27 2013
prev sibling next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Saturday, 26 January 2013 at 22:23:05 UTC, mist wrote:

 There was discussion recently about unpleasant name conflict 
 possible with private module symbols. I have just encountered a 
 sarcastically false statement on dlang.org : "Private module 
 members are equivalent to static declarations in C programs."

 Made me sad and wondering: was there any DIP after that thread 
 or it has ended, as it often happens, with a decision to "plan 
 carefully"? In latter case I may try to write one.


Can you explain what is broken ?
Jan 27 2013
parent reply "Dicebot" <m.strashun gmail.com> writes:
Most annoying for me:

$ cat mod1.d
module mod1;

private void func(int) { }

$ cat mod2.d
import mod1;

void main() { func(42); }

$ rdmd mod2.d
mod2.d(3): Error: module mod2 mod1.func is private
mod2.d(3): Error: function mod1.func is not accessible from 
module mod2

With static in C and unnamed namespace in C++ those symbols do 
not participate in outer name resolution at all and do not exist 
as symbols in resulting object file.

Probably there are others, more subtle issues. I'll need to 
re-parse all discussion in that topic if going to try do a DIP 
about it.
Jan 27 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/27/13 8:58 AM, Dicebot wrote:

 Most annoying for me:

 $ cat mod1.d
 module mod1;

 private void func(int) { }

 $ cat mod2.d
 import mod1;

 void main() { func(42); }

 $ rdmd mod2.d
 mod2.d(3): Error: module mod2 mod1.func is private
 mod2.d(3): Error: function mod1.func is not accessible from module mod2

 With static in C and unnamed namespace in C++ those symbols do not
 participate in outer name resolution at all and do not exist as symbols
 in resulting object file.

 Probably there are others, more subtle issues. I'll need to re-parse all
 discussion in that topic if going to try do a DIP about it.


I agree that mod1.func should not even be visible from mod2.

Andrei
Jan 27 2013
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 27 January 2013 at 14:27:21 UTC, Andrei Alexandrescu 
wrote:

 I agree that mod1.func should not even be visible from mod2.


Not even via reflection ?
Jan 27 2013
next sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Sunday, 27 January 2013 at 14:43:26 UTC, deadalnix wrote:

 On Sunday, 27 January 2013 at 14:27:21 UTC, Andrei Alexandrescu 
 wrote:

 I agree that mod1.func should not even be visible from mod2.


 Not even via reflection ?


Debatable, so far I am planning to propose full hiding. No direct 
reflection, no DDOC via import, no trace of symbol in object 
file. Like it was possible in C/C++. Detailed investigation may 
reveal valid use cases though, than design may need to become 
more complex.
Jan 27 2013
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/27/13 9:43 AM, deadalnix wrote:

 On Sunday, 27 January 2013 at 14:27:21 UTC, Andrei Alexandrescu wrote:

 I agree that mod1.func should not even be visible from mod2.


 Not even via reflection ?


Not even. Note that private struct/class member visibility via 
reflection is a different matter.

Andrei
Jan 27 2013
prev sibling parent reply "Dicebot" <m.strashun gmail.com> writes:
OK, I have gathered most of the data I wanted and writing DIP 
right now.

Only moment not perfectly clear for me are serialization 
libraries and private. Can someone who has been doing similar 
things provide few snippets of serializing fields/variables 
serializer has no access to, in a way it is done now?

I have asked Jacob via e-mail about his Orange but may be someone 
else can stand up.
Jan 28 2013
next sibling parent reply "Dicebot" <m.strashun gmail.com> writes:
P.S. Raw data I am making decisions on top of sits here: 
http://wiki.dlang.org/Access_specifiers_and_visibility . Everyone 
is welcome to correct me in the wrong parts.
Jan 28 2013
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Monday, 28 January 2013 at 14:18:38 UTC, Dicebot wrote:

 P.S. Raw data I am making decisions on top of sits here: 
 http://wiki.dlang.org/Access_specifiers_and_visibility . 
 Everyone is welcome to correct me in the wrong parts.


Very good job !

But is more a stating of how things are now rather than a DIP.
Jan 28 2013
parent "Dicebot" <m.strashun gmail.com> writes:
On Monday, 28 January 2013 at 14:28:00 UTC, deadalnix wrote:

 On Monday, 28 January 2013 at 14:18:38 UTC, Dicebot wrote:

 P.S. Raw data I am making decisions on top of sits here: 
 http://wiki.dlang.org/Access_specifiers_and_visibility . 
 Everyone is welcome to correct me in the wrong parts.


 Very good job !

 But is more a stating of how things are now rather than a DIP.


Ye, thus I have said "raw data" and "I am writing DIP now" :)
I have just gathered all related stuff together to get a big 
picture and leave no issues unresolved by DIP. DIP itself will be 
published either this evening (GMT +0) or tomorrows morning.
Jan 28 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-01-28 15:15, Dicebot wrote:

 OK, I have gathered most of the data I wanted and writing DIP right now.

 Only moment not perfectly clear for me are serialization libraries and
 private. Can someone who has been doing similar things provide few
 snippets of serializing fields/variables serializer has no access to, in
 a way it is done now?

 I have asked Jacob via e-mail about his Orange but may be someone else
 can stand up.


Orange uses ".tupleof" to iterate all fields and also to get/set the 
value of a field. This will bypass the protection attribute and allows 
to get/set private/protected/package fields. The serializer would be a 
lot less user friendly if the user had to manually serialize each 
protected field.

The serializer also uses __traits(getAttribute) for the fields and 
classes/structs to any attached attributes. If the above cannot work for 
private fields I guess there's back to using mixins to a static fields 
which are a uglier than attributes.

-- 
/Jacob Carlborg
Jan 28 2013
parent reply "David Nadlinger" <see klickverbot.at> writes:
On Monday, 28 January 2013 at 20:10:16 UTC, Jacob Carlborg wrote:

 The serializer would be a lot less user friendly if the user 
 had to manually serialize each protected field.


Can Orange work on structs/classes that have not been intended to 
be used with it, e.g. imported from some other arbitrary module?

If not (and your mention of annotations seems to suggest that), 
the easiest solution would be to just provide the serialization 
code in the module where the class is defined (e.g. a public 
static member function), no?

David
Jan 28 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-01-28 21:15, David Nadlinger wrote:


 Can Orange work on structs/classes that have not been intended to be
 used with it, e.g. imported from some other arbitrary module?


Yes. It can serialize arbitrary third party types without any extra code.


 If not (and your mention of annotations seems to suggest that), the
 easiest solution would be to just provide the serialization code in the
 module where the class is defined (e.g. a public static member
 function), no?


That's also possible.

-- 
/Jacob Carlborg
Jan 28 2013