www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - private keyword dont appear to do anything

reply LunaticWare <exemple gmail.com> writes:
hello, being new to D i assumed that the private keyword would 
work as in C++, but writing this code, i excepted it to throw an 
error at compile time, it appear to not doing anything, is there 
something i am doing wrong ?

------
import std.stdio;

class Foo
{
     private int id = 10;
}

struct Bar
{
     private int id = 20;
}

void main()
{
     auto foo = new Foo;
     Bar bar;

     foo.id = 15;
     bar.id = 25;

     writeln(foo.id);
     writeln(bar.id);
}

// RDMD OUTPUT
// 15
// 25
Nov 03
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
Visibility modifiers like private, and public are to the module not the 
scope.

"Symbols with private visibility can only be accessed from within the 
same module."

This is how module based languages work, a bit more useful then to the 
scope approach IMO. An easy mistake to make.

https://dlang.org/spec/attribute.html#visibility_attributes
Nov 03
next sibling parent LunaticWare <exemple gmail.com> writes:
On Friday, 3 November 2017 at 12:43:15 UTC, rikki cattermole 
wrote:
 Visibility modifiers like private, and public are to the module 
 not the scope.

 "Symbols with private visibility can only be accessed from 
 within the same module."

 This is how module based languages work, a bit more useful then 
 to the scope approach IMO. An easy mistake to make.

 https://dlang.org/spec/attribute.html#visibility_attributes
thank you
Nov 03
prev sibling next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Friday, November 03, 2017 13:43:15 rikki cattermole via Digitalmars-d-
learn wrote:
 Visibility modifiers like private, and public are to the module not the
 scope.

 "Symbols with private visibility can only be accessed from within the
 same module."

 This is how module based languages work, a bit more useful then to the
 scope approach IMO. An easy mistake to make.

 https://dlang.org/spec/attribute.html#visibility_attributes
To be fair, there are times where it would arguably be desirable to restrict private to a struct or class, so it's not all wonderful, but it does mean that we don't have to have the extra complication of friend functions like C++ does (which I believe is the biggest motivation for it). And if a module is so large that you can't make sure that nothing is accessing private struct or class members when it shouldn't, then the module is probably overly large and/or complicated. Most folks are surprised by this behavior, and occasionally, they complain about it, but in practice, the only real problem that I'm aware of is that you can sometimes write unit tests which work just because they're in the module, and the code doesn't work when used outside of the module. But even that tends to be only an occasional problem. - Jonathan M Davis
Nov 03
parent reply Nathan S. <no.public.email example.com> writes:
On Friday, 3 November 2017 at 20:01:27 UTC, Jonathan M Davis 
wrote:
 Most folks are surprised by this behavior
I found it surprising at first but now any other way seems absurd to me. None of the benefits of data encapsulation apply to code written five lines away in the same file.
Nov 03
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Nov 03, 2017 at 09:08:56PM +0000, Nathan S. via Digitalmars-d-learn
wrote:
 On Friday, 3 November 2017 at 20:01:27 UTC, Jonathan M Davis wrote:
 Most folks are surprised by this behavior
I found it surprising at first but now any other way seems absurd to me. None of the benefits of data encapsulation apply to code written five lines away in the same file.
This is a good point. :-) Though in practice, source files do tend to get long... I've had to work with source files over 8000+ lines long, and having encapsulation between two distant parts of the file can be useful. However, even then, one can argue that any benefits of encapsulation you may have are already negated by the very-not-encapsulated practice of an 8000-line long source file, so the point is moot anyway. T -- Don't get stuck in a closet---wear yourself out.
Nov 03
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 11/3/17 5:08 PM, Nathan S. wrote:
 On Friday, 3 November 2017 at 20:01:27 UTC, Jonathan M Davis wrote:
 Most folks are surprised by this behavior
I found it surprising at first but now any other way seems absurd to me. None of the benefits of data encapsulation apply to code written five lines away in the same file.
I also enjoy the mechanism, but I have to call this out as incorrect. Encapsulation is about being able to prove to yourself exactly how an object's private data can possibly be manipulated. It's not just 5 lines away, it's the whole file you have to review. If you have large flat files like Phobos, then encapsulation is essentially impossible to review. -Steve
Nov 03
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Nov 03, 2017 at 05:43:55PM -0400, Steven Schveighoffer via
Digitalmars-d-learn wrote:
 On 11/3/17 5:08 PM, Nathan S. wrote:
 On Friday, 3 November 2017 at 20:01:27 UTC, Jonathan M Davis wrote:
 Most folks are surprised by this behavior
I found it surprising at first but now any other way seems absurd to me. None of the benefits of data encapsulation apply to code written five lines away in the same file.
I also enjoy the mechanism, but I have to call this out as incorrect. Encapsulation is about being able to prove to yourself exactly how an object's private data can possibly be manipulated. It's not just 5 lines away, it's the whole file you have to review. If you have large flat files like Phobos, then encapsulation is essentially impossible to review.
[...] Arguably, many of these large flat files ought to be split up into smaller files. For example, std.algorithm.* and std.range.* all tend to be conglomerations of basically-independent groups of structs and functions. Iota and Cycle never interact with each other, and neither of them interacts with Recurrence, yet these all sit in the same file. Seems to me like a typical case of low cohesion, which, according to the ideals of encapsulation, ought to be grounds for splitting up the file into self-contained parts. But of course, there are pragmatic reasons for the way things currently are. T -- Государство делает вид, что платит нам зарплату, а мы делаем вид, что работаем.
Nov 03
prev sibling next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Friday, November 03, 2017 14:52:22 H. S. Teoh via Digitalmars-d-learn 
wrote:
 On Fri, Nov 03, 2017 at 05:43:55PM -0400, Steven Schveighoffer via 
Digitalmars-d-learn wrote:
 On 11/3/17 5:08 PM, Nathan S. wrote:
 On Friday, 3 November 2017 at 20:01:27 UTC, Jonathan M Davis wrote:
 Most folks are surprised by this behavior
I found it surprising at first but now any other way seems absurd to me. None of the benefits of data encapsulation apply to code written five lines away in the same file.
I also enjoy the mechanism, but I have to call this out as incorrect. Encapsulation is about being able to prove to yourself exactly how an object's private data can possibly be manipulated. It's not just 5 lines away, it's the whole file you have to review. If you have large flat files like Phobos, then encapsulation is essentially impossible to review.
[...] Arguably, many of these large flat files ought to be split up into smaller files. For example, std.algorithm.* and std.range.* all tend to be conglomerations of basically-independent groups of structs and functions. Iota and Cycle never interact with each other, and neither of them interacts with Recurrence, yet these all sit in the same file. Seems to me like a typical case of low cohesion, which, according to the ideals of encapsulation, ought to be grounds for splitting up the file into self-contained parts. But of course, there are pragmatic reasons for the way things currently are.
If you take that to the extreme, you just end up with a function per module, which is pretty ridiculous IMHO (though that may be what you mean by pragmatic reasons). And really, free functions like that are exactly the sort of places where encapsulation tends not to matter much, because there's nothing to encapsulate beyond the guts of the functions themselves, which are already encapsulated. The situation is very different from something like std.container where you have types which have member variables which could be protected from access by other stuff in their modules if private worked differently. Figuring out a good way to organize a bunch of free functions is difficult (as evidenced by the fact that plenty of folks have a hard time remembering what is where inside of std.algorithm and std.range), but that's really not an encapsulation problem, just a code organization problem. - Jonathan M Davis
Nov 03
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Nov 03, 2017 at 04:30:21PM -0600, Jonathan M Davis via
Digitalmars-d-learn wrote:
 On Friday, November 03, 2017 14:52:22 H. S. Teoh via Digitalmars-d-learn 
 wrote:
[...]
 Arguably, many of these large flat files ought to be split up into
 smaller files.  For example, std.algorithm.* and std.range.* all
 tend to be conglomerations of basically-independent groups of
 structs and functions.  Iota and Cycle never interact with each
 other, and neither of them interacts with Recurrence, yet these all
 sit in the same file.

 Seems to me like a typical case of low cohesion, which, according to
 the ideals of encapsulation, ought to be grounds for splitting up
 the file into self-contained parts.

 But of course, there are pragmatic reasons for the way things
 currently are.
If you take that to the extreme, you just end up with a function per module, which is pretty ridiculous IMHO (though that may be what you mean by pragmatic reasons).
It's not that ridiculous if you consider that some of the more heavily-used Phobos functions are actually not individual functions, but overload sets. I know we have been trying to merge some of the unnecessary overload sets for other reasons, but some of these overload sets can get pretty big. Compound that with the long string of unittests associated with each overload, that has accumulated from a long string of bug fixes, etc., and you have pretty good justification for keeping just that single overload set in its own file, together with its associated unittests, and potentially also other paraphrenalia like enums or other declarations used by the overload set, but not used anywhere else.
 And really, free functions like that are exactly the sort of places
 where encapsulation tends not to matter much, because there's nothing
 to encapsulate beyond the guts of the functions themselves, which are
 already encapsulated.
Arguably, once a function grows past a certain length, it's time to break it down into more manageable pieces. Having a function sit in its own file gives you a nice working space for this sort of refactoring, without worrying about namespace conflicts with unrelated code. Still, I agree that some degree of judgment is involved here. If we're talking about a simple function that will never grow past 5-10 lines, it does seem a little pointless to keep it in its own file, just to adhere to some ideal of encapsulation. But IME, with Phobos code even simple functions eventually grow into multi-page monsters over time, once you start adding type-specific specializations to deal with performance issues and the like. Just look at std.algorithm.searching.find, for example. Several different overloads, and static if blocks within an overload, sometimes on the lengthy side depending on the specific optimization being implemented. Arguably we should factor out some of the static if blocks or overloads into separate private functions for easier future maintenance / management if more specializations are added, or we need to balance between different optimizations based on different factors. Static-if / else blocks just aren't very conducive to this sort of thing. And being able to do this in a file dedicated to .find would be cleaner than having to do surgery in a 4600-line file (and having to deal with potential merge conflicts with other unrelated changes to the same file -- though git is so good at this that one generally doesn't run into much of a problem).
 The situation is very different from something like std.container
 where you have types which have member variables which could be
 protected from access by other stuff in their modules if private
 worked differently.
Well, std.container *has* been split into submodules per container type. I think that's a much better organization than in std.algorithm.*.
 Figuring out a good way to organize a bunch of free functions is
 difficult (as evidenced by the fact that plenty of folks have a hard
 time remembering what is where inside of std.algorithm and std.range),
 but that's really not an encapsulation problem, just a code
 organization problem.
[...] <half-serious> Perhaps the solution is to go the one-overload-set-per-file route, with std/algorithm/package.d basically importing everything underneath. :-P </half-serious> (Shhh, don't tell Andrei, or we'll get another lecture about wasting time on worthless things while more important things are left to do.) T -- All problems are easy in retrospect.
Nov 03
parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Friday, 3 November 2017 at 23:32:52 UTC, H. S. Teoh wrote:
 [...]
What's wrong with the introduction of another visibility attribute that behave like the C++ private? Just curious... --- Paolo
Nov 04
parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Saturday, November 04, 2017 11:03:52 Paolo Invernizzi via Digitalmars-d-
learn wrote:
 On Friday, 3 November 2017 at 23:32:52 UTC, H. S. Teoh wrote:
 [...]
What's wrong with the introduction of another visibility attribute that behave like the C++ private? Just curious...
Well, if a good enough DIP could be written to convince Walter and Andrei, then I'm sure it could be added, but it probably isn't worth it. If you really want that level of separation, then you can always just put your class or struct in its own module, and in practice, the fact that other stuff in a module _could_ access the private members of a struct or class doesn't tend to be a problem - and adding yet another access modifier does make the language and its implementation that much more complicated. It also might break existing code that uses type introspection and has logic based on what access level a symbol has. Ultimately, while I don't think that there's any technical reason why we couldn't make such a change, I think that it's trying to solve a problem that doesn't really exist, and for the change to be made, a solid argument would have to be made as to why it's a real problem that needs fixing and why the proposed solution is the right one. - Jonathan M Davis
Nov 04
prev sibling parent Basile B. <b2.temp gmx.com> writes:
On Friday, 3 November 2017 at 12:43:15 UTC, rikki cattermole 
wrote:
 Visibility modifiers like private, and public are to the module 
 not the scope.

 "Symbols with private visibility can only be accessed from 
 within the same module."

 This is how module based languages work,
Pascal has "strict private". I like it because you can enforce the usage of setters and getters within the same module. http://wiki.freepascal.org/User_Changes_3.0#.22strict_protected.22_visibility_modifier To have strict privacy in D we have to isolate the "strict" thing in a file.
Nov 04
prev sibling next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Friday, November 03, 2017 16:32:52 H. S. Teoh via Digitalmars-d-learn 
wrote:
 <half-serious> Perhaps the solution is to go the
 one-overload-set-per-file route, with std/algorithm/package.d basically
 importing everything underneath. :-P </half-serious>

 (Shhh, don't tell Andrei, or we'll get another lecture about wasting
 time on worthless things while more important things are left to do.)
Actually, when Daniel and I were trying to talk Walter into adding the package.d feature so that std.datetime could be split up without breaking code, Walter made a comment about how he didn't see any problem with there being a function per module. So, he might be on board with code arrangements along those lines, but I have no idea about Andrei. Personally, I think that splitting stuff up that far makes it a pain to deal with, even if it might help the implementation sometimes. It's already really annoying that I have to figure out which module something in std.algorithm is in now, because the style check junk that has been added to Phobos requires that you not only use selective imports but that you use the module that it's directly in, so you can't do something like import std.algorithm : map; but instead have to go figure out which module it's currently living in and add that after std.algorithm. Of course, I also don't generally have a problem with large modules. They _can_ become large enough to become a problem, but I've found that I have a much higher tolerance for how much goes in a single file than many of the D devs seem to have. IMHO, the main thing that starts causing problems with large modules is when you start doing stuff like using attribute labels like safe: or attribute blocks like safe { } because then it becomes difficult to know which attributes actually apply to a piece of code. Most stuff is self-contained enough that having a bunch of stuff in a single module frequently isn't a real problem. So, if they're related enough, I have no problem with it. But good organization is arguably difficult to get right and highly subjective - just like naming stuff is. Where you risk running into serious problems is where you have a large module full of interdependent stuff, because then it's all highly coupled and hard to keep track of, so it becomes hard to understand and maintain. You can have the same problems across modules, but when you split stuff up across modules, it tends to force you to think about things differently so that you don't make everything so highly coupled - though a bad programmer (or a good programmer having a bad day) can make any code a mess. - Jonathan M Davis
Nov 03
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Nov 03, 2017 at 05:59:20PM -0600, Jonathan M Davis via
Digitalmars-d-learn wrote:
 On Friday, November 03, 2017 16:32:52 H. S. Teoh via Digitalmars-d-learn 
 wrote:
 <half-serious> Perhaps the solution is to go the
 one-overload-set-per-file route, with std/algorithm/package.d
 basically importing everything underneath. :-P </half-serious>

 (Shhh, don't tell Andrei, or we'll get another lecture about wasting
 time on worthless things while more important things are left to
 do.)
Actually, when Daniel and I were trying to talk Walter into adding the package.d feature so that std.datetime could be split up without breaking code, Walter made a comment about how he didn't see any problem with there being a function per module. So, he might be on board with code arrangements along those lines, but I have no idea about Andrei.
I got chastised by Andrei for doing the std.algorithm split. He only conceded after I stated that I couldn't run the std.algorithm unittests on my PC anymore because it was taking up GBs of memory. Based on that I'm assuming he would likely be opposed to yet another refactoring of std.algorithm. :-D
 Personally, I think that splitting stuff up that far makes it a pain
 to deal with, even if it might help the implementation sometimes. It's
 already really annoying that I have to figure out which module
 something in std.algorithm is in now, because the style check junk
 that has been added to Phobos requires that you not only use selective
 imports but that you use the module that it's directly in, so you
 can't do something like
 
 import std.algorithm : map;
 
 but instead have to go figure out which module it's currently living
 in and add that after std.algorithm.
If we split everything into its own module, presumably the module would be named after the function itself, and would inherit directly from the top-level std.algorithm package. So it would be a simple matter of going to std/algorithm/${function_name}.d to find the code, which arguably would be *simpler* than it is today. But again, I'm not seriously proposing this, and I doubt we'd actually do it anyway. The sheer amount of effort involved, plus potential user code breakage (explicit imports of std.algorithm.searching, for example, would break, unless we keep searching.d around as just a bunch of public imports, which is kinda ugly), yielding only marginal benefits. I just don't see W & A approving of something like that. [...]
 Where you risk running into serious problems is where you have a large
 module full of interdependent stuff, because then it's all highly
 coupled and hard to keep track of, so it becomes hard to understand
 and maintain.  You can have the same problems across modules, but when
 you split stuff up across modules, it tends to force you to think
 about things differently so that you don't make everything so highly
 coupled - though a bad programmer (or a good programmer having a bad
 day) can make any code a mess.
[...] "Real Programmers can write assembly code in any language." :-D T -- Winners never quit, quitters never win. But those who never quit AND never win are idiots.
Nov 03