Re: how to make private class member private
On Sunday, 18 March 2018 at 18:45:23 UTC, Steven Schveighoffer
wrote:
unittest
{
auto foo = new Foo;
assert(foo.internalbuffer.empty); // note, this is a private
symbol.
}
I don't understand why you would want a private symbol in a
*documented* unittest, the reader of the *documentation* will not
be able to run the example code.
I can do the same thing in ddoc, but without the benefit of
having the unit test run.
You mean not using a unittest?
Forcing me to do it that way is just annoying (I will have to
duplicate the code).
If you really want your documented unittests not to be runnable
by a user, you can have a free function with `protected` access
as a workaround.
Re: how to make private class member private
On Monday, 19 March 2018 at 01:11:43 UTC, psychoticRabbit wrote: The fact that the creator of a class, is also the creator of the module that contains that class, is not a valid reason for not seeking to improve encapsulation of that class. I agree with this. This especially matters with projects where multiple people might work on the same module. You might not want to expose every member to all the people who work on the module. Whereas you might want other members to be exposed to the module and not outside, so the argument for putting the class into a new module doesn't work either, since the members you do want to expose cannot be exposed, unless they're public, in which case it defeats the whole purpose of encapsulation. Yes, it's great that private is module-level by default, but it just doesn't work in practice with modules worked on by multiple people. Tons of bugs can be avoided too, like a few times unittests have passed in phobos with traits because private members were visible in the module. (I can't remember a specific example on top of my head, but it has happened a few times.)
Re: how to make private class member private
On Sunday, 18 March 2018 at 18:45:23 UTC, Steven Schveighoffer wrote: If we could go back in time and talk with a young Walter about the consequences of choosing the scheme the way it is, maybe he might have made different choices, but at this point, it's hard to change it. I think this highlights the real problem with D. Power is too centralised, and kinda arbitrary. I'm going back to Java ;-)
Re: how to make private class member private
On Sunday, 18 March 2018 at 11:12:46 UTC, Alex wrote: ´´´ Are there any scenarios in which the person writing the class, would want to encapsulate their class, or some parts of it, from the rest of a module (while being forced to put the class in this module)? ´´´ The answer is no. As the person which is writing the class has always the power to decide which module to edit to put the class in. And due this fact, the statement The fact is, the creator of the class is also the creator of the module.. is the coolest semantic statement of the whole thread so far, I think :) Well, it seems to me, that the only real objection one can have to improving encapsulation within a module, is objecting to improving encapsulation within a module. The fact that the creator of a class, is also the creator of the module that contains that class, is not a valid reason for not seeking to improve encapsulation of that class.
Re: how to make private class member private
On Sunday, 18 March 2018 at 18:04:13 UTC, Tony wrote: On Tuesday, 13 March 2018 at 06:03:11 UTC, Mike Parker wrote: D is not C++, C#, or Java. C++ uses friend to get around the issue. Java has no solution. I don't know about C#. Java has four protection levels. If you don't explicitly specify [private, protected, public] the protection level is implicitly "package-private". That means that any class in the same package can access that attribute. I believe that Java packages are identical to D packages. https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/accessibility-levels C# has 6 accessibility levels: public - Access is not restricted. protected - Access is limited to the containing class or types derived from the containing class. private - Access is limited to the containing type. internal - Access is limited to the current assembly. protected internal - Access is limited to the current assembly or types derived from the containing class. private protected - Access is limited to the containing class or types derived from the containing class within the current assembly. Available since C# 7.2. What is a C# Assembly? Someone says on a forum: "An assembly is a "unit of deployment" for .NET, almost always a .exe or .dll. In C# terms, it's basically a single C# project." And also refers to https://social.msdn.microsoft.com/Forums/en-US/088ce8ed-ef9b-4dea-88b3-ca016885e26d/what-is-an-assembly-in-terms-of-c?forum=csharplanguage which says: "Assemblies are the building blocks of .NET Framework applications; they form the fundamental unit of deployment, version control, reuse, activation scoping, and security permissions. An assembly is a collection of types and resources that are built to work together and form a logical unit of functionality. An assembly provides the common language runtime with the information it needs to be aware of type implementations. To the runtime, a type does not exist outside the context of an assembly."
Re: how to make private class member private
On Sunday, March 18, 2018 18:59:39 Tony via Digitalmars-d-learn wrote: > On Sunday, 18 March 2018 at 18:32:42 UTC, Jonathan M Davis wrote: > > They're similar, but there are differences. For instance, you > > can do package(a) in D in order to do something like put the > > stuff in a.b.c in package a rather than a.b. > > Is there a known situation where it makes sense to put module c > in directory/package b - rather than directory/package a, and > then tell the D compiler to treat it like it was in > directory/package a? I don't think that you can have anything in a/b/c.d marked as if it were in package a/z. It's only for putting stuff higher up in the package hierarchy while allowing it to be placed in modules deeper in the hierarchy, not for moving it laterally within the package hierarchy. One place where it's used (and which IIRC was the motivating reason for its implementation) is std.internal.* in Phobos. At least some of what's there is marked with package(std) (and probably all of it should be, but a lot of it predates the improvement to package). That way, stuff that's essentially private to Phobos can be organized there but be used by anything in Phobos, whereas without the improvement to package, they'd all have to be modules directly under std (probably all with internal in their module names) in order to have them being treated as being in the std package. So, ultimately, it's about better organization and probably is something that only makes sense for when entire modules are essentially private to a library and not for modules that mix public and package symbols. - Jonathan M Davis
Re: how to make private class member private
On Sunday, 18 March 2018 at 18:32:42 UTC, Jonathan M Davis wrote: They're similar, but there are differences. For instance, you can do package(a) in D in order to do something like put the stuff in a.b.c in package a rather than a.b. Is there a known situation where it makes sense to put module c in directory/package b - rather than directory/package a, and then tell the D compiler to treat it like it was in directory/package a?
Re: how to make private class member private
On 3/17/18 5:56 AM, Nick Treleaven wrote:
On Tuesday, 13 March 2018 at 13:59:00 UTC, Steven Schveighoffer wrote:
If you limit to class members, then you have to do something like C++
friends, which are unnecessarily verbose.
Not if you also have a module-level visibility modifier, which could
have been `module`.
If we could go back in time and talk with a young Walter about the
consequences of choosing the scheme the way it is, maybe he might have
made different choices, but at this point, it's hard to change it.
Note, again, you can do pretty much every privacy scheme you want with
package modules today. Before, it was a lot less nice.
It's pretty simple: all your friends go into the module. All your
external functions that should only use the public API have to go
elsewhere. I think the thing that bites people is simply that they
aren't used to it.
IMO, the module-level encapsulation is the right choice. It helps with
a lot of key features:
1. IFTI factory methods
Aren't these mainly because constructors can't use IFTI, unlike C++17,
While this is a limitation that I wish wasn't there, constructors aren't
always the best way to build a type.
But there are other reasons to put functions that access private pieces
outside the aggregate. For instance, if you want to accept a struct by
value.
2. unittests
Documented unittests should not be allowed to use private symbols, I
just filed this:
https://issues.dlang.org/show_bug.cgi?id=18623
Why not?
unittest
{
auto foo = new Foo;
assert(foo.internalbuffer.empty); // note, this is a private symbol.
}
I can do the same thing in ddoc, but without the benefit of having the
unit test run. Forcing me to do it that way is just annoying (I will
have to duplicate the code).
-Steve
Re: how to make private class member private
On Sunday, March 18, 2018 18:04:13 Tony via Digitalmars-d-learn wrote: > On Tuesday, 13 March 2018 at 06:03:11 UTC, Mike Parker wrote: > > D is not C++, C#, or Java. C++ uses friend to get around the > > issue. Java has no solution. I don't know about C#. > > Java has four protection levels. If you don't explicitly specify > [private, protected, public] the protection level is implicitly > "package-private". That means that any class in the same package > can access that attribute. I believe that Java packages are > identical to D packages. They're similar, but there are differences. For instance, you can do package(a) in D in order to do something like put the stuff in a.b.c in package a rather than a.b. Also, package functions in D are never virtual, which I expect is not the case for Java. The whole situation is also complicated somewhat by the fact that D allows pretty much anything at module-level, whereas as Java requires one class per module, though I'm not sure that that has much direct effect on package itself other than the fact that it's possible in D to mark stuff package that isn't in a class. - Jonathan M Davis
Re: how to make private class member private
On Tuesday, 13 March 2018 at 06:03:11 UTC, Mike Parker wrote: D is not C++, C#, or Java. C++ uses friend to get around the issue. Java has no solution. I don't know about C#. Java has four protection levels. If you don't explicitly specify [private, protected, public] the protection level is implicitly "package-private". That means that any class in the same package can access that attribute. I believe that Java packages are identical to D packages.
Re: how to make private class member private
On Sunday, 18 March 2018 at 10:45:55 UTC, psychoticRabbit wrote: On Sunday, 18 March 2018 at 10:14:30 UTC, Alain Soap wrote: [...] " Private - All fields and methods that are in a private block, can only be accessed in the module (i.e. unit) that contains the class definition. They can be accessed from inside the classes’ methods or from outside them (e.g. from other classes’ methods)" " Strict Private - All fields and methods that are in a strict private block, can only be accessed from methods of the class itself. Other classes or descendent classes (even in the same unit) cannot access strict private members. " https://www.freepascal.org/docs-html/ref/refse34.html interesting...someone else clearly had the idea. hey..perhaps I'm not a moron after all. Change your pseudo.
Re: how to make private class member private
On Sunday, 18 March 2018 at 09:56:31 UTC, psychoticRabbit wrote: However, are there no scenarios in which the person writing that module, would not want to encapsulate their class, or some parts of it, from the rest of the module (while not being forced to put the class in it's own file)? If the answer is certainly no, not under any circumstances, then fine, my idea is not worth any further consideration. And by no, I mean no for all, not just you. I assume, that the following statement is equivalent to yours: ´´´ Are there any scenarios in which the person writing the class, would want to encapsulate their class, or some parts of it, from the rest of a module (while being forced to put the class in this module)? ´´´ The answer is no. As the person which is writing the class has always the power to decide which module to edit to put the class in. And due this fact, the statement The fact is, the creator of the class is also the creator of the module.. is the coolest semantic statement of the whole thread so far, I think :)
Re: how to make private class member private
On Sunday, 18 March 2018 at 10:14:30 UTC, Alain Soap wrote: BTW i think adding this can be useful. The FreePascal language has `strict private` for example. " Private - All fields and methods that are in a private block, can only be accessed in the module (i.e. unit) that contains the class definition. They can be accessed from inside the classes’ methods or from outside them (e.g. from other classes’ methods)" " Strict Private - All fields and methods that are in a strict private block, can only be accessed from methods of the class itself. Other classes or descendent classes (even in the same unit) cannot access strict private members. " https://www.freepascal.org/docs-html/ref/refse34.html interesting...someone else clearly had the idea. hey..perhaps I'm not a moron after all.
Re: how to make private class member private
On Saturday, 17 March 2018 at 23:54:22 UTC, psychoticRabbit wrote:
On Saturday, 17 March 2018 at 21:33:01 UTC, Adam D. Ruppe wrote:
On Saturday, 17 March 2018 at 21:22:44 UTC, arturg wrote:
maybe extend that to a list of types?
this is basically what C++ friend does and D was trying to
avoid the complexity of
Really, the complexity of 'friend' comes from people abusing it.
In D, I would prefer no breaking change here. Leave private as
it is.
Just a simple attribute that only applies within a class, and
only to private members within that class.
@strictly private string firstName_;
Nothing outside of the class, not even the module, can access
this now. It's all encapsulated.
It breaks nothing (AFAIK).
It's very clear what the intention is here.
It's an easy attribute to remember.
It restores the principle of class enscapsulation within a
module, for when it's really needed.
Now D programmers would have the best of both worlds.
Yesterday i thought to reuse `super`:
struct Foo
{
super private:
int _stats;
int _field;
public:
int field(){_stats++; return _field;}
void field(int value){_stats++; _field = value;}
}
BTW i think adding this can be useful. The FreePascal language
has `strict private` for example.
Re: how to make private class member private
On Sunday, 18 March 2018 at 05:01:39 UTC, Amorphorious wrote: The fact is, the creator of the class is also the creator of the module.. and preventing him from having full access to the class is ignorant. He doesn't need to encapsulate himself. Encapsulation is ONLY meant to reduce dependencies. If the programmer, probably someone like you, can't trust himself to understand his own code then he shouldn't be coding. btw. I am talking here about 'encapsulation' not 'information hiding' (although the two terms are often considered related). Clearly, there is no point in hiding information contained within the module, from the implementer of the module. That's just silly. However, are there no scenarios in which the person writing that module, would not want to encapsulate their class, or some parts of it, from the rest of the module (while not being forced to put the class in it's own file)? If the answer is certainly no, not under any circumstances, then fine, my idea is not worth any further consideration. And by no, I mean no for all, not just you.
Re: how to make private class member private
On Saturday, 17 March 2018 at 23:54:22 UTC, psychoticRabbit wrote: In D, I would prefer no breaking change here. Leave private as it is. My suggestion has no breaking change and it works just like the package attribute already works. Also you shouldn't allow multiple types for it, that would defeat the purpose of private again and in that case you should just use as is, since module-level private can already ensure that. If you need to share it with types outside of the module, then it's pointless, because you're essentially just duck-taping an issue of your program design and not the language design.
Re: how to make private class member private
On Sunday, 18 March 2018 at 05:01:39 UTC, Amorphorious wrote: Why do you insist that you know how everything works and you are the harbinger of truth. The fact is, you don't know squat about what you are talking about and you just want to conform D to your naive ignorant ...etc...etc..etc..etc..etc you're funny. and btw. My suggestion would not stop anyone from doing what they're currently doing within modules. It would just return class encapsulation, within a module, for when it was deemed worthwhile (as opposed to being forced to move the class out of the module). It's just an idea, not a request. One day I might do a data matching analysis of the dmail-archive, to find out who you really are.
Re: how to make private class member private
On Saturday, 17 March 2018 at 23:54:22 UTC, psychoticRabbit wrote: On Saturday, 17 March 2018 at 21:33:01 UTC, Adam D. Ruppe wrote: On Saturday, 17 March 2018 at 21:22:44 UTC, arturg wrote: maybe extend that to a list of types? this is basically what C++ friend does and D was trying to avoid the complexity of Really, the complexity of 'friend' comes from people abusing it. In D, I would prefer no breaking change here. Leave private as it is. Just a simple attribute that only applies within a class, and only to private members within that class. @strictly private string firstName_; Nothing outside of the class, not even the module, can access this now. It's all encapsulated. It breaks nothing (AFAIK). It's very clear what the intention is here. It's an easy attribute to remember. It restores the principle of class enscapsulation within a module, for when it's really needed. Now D programmers would have the best of both worlds. Why do you insist that you know how everything works and you are the harbinger of truth. The fact is, you don't know squat about what you are talking about and you just want to conform D to your naive ignorant understanding of programming so you don't get confused rather than learning and accepting D for what it does, which is do everything better than C/C++. You keep trying to make it in to C/C++, the the hell don't you just go use C/C++ then? No one is going to listen to you. Your ignorance is pointed out by many that have used D far longer than you have and you think you can come in and point out all the things wrong without having any experience with it. The fact is, the creator of the class is also the creator of the module.. and preventing him from having full access to the class is ignorant. He doesn't need to encapsulate himself. Encapsulation is ONLY meant to reduce dependencies. If the programmer, probably someone like you, can't trust himself to understand his own code then he shouldn't be coding. If you don't like it, just write one class per module and don't have any free functions... it solves your problem and it doesn't use your shitty "solution". No one is forcing you to access your class outside the class but inside the module. The fact is you are ignorant of what you speak about and that is 99% of the problem. If you don't like how D does it, go use another language that does it the way you "think"(if you could call it that) is correct. Many of the thing D does is learned from the mistakes of C/C++... and for you to pretend that your insignificant self who has never wrote a compiler much less read the specs has a clue about the ramifications of the changes is moronic. Your only reason for not liking it is because you "don't like it"... how moronic. "Mmm.. I don't think I like it. I feel you should be able to make a member of a class, private, regardless of where the class is located. This seems to break the concept of class encapsulation. No. I don't like it at all. " Yet you have no clue... You "learned"(brainwashed" that encapsulation means private members of classes cannot be accessed from C++ and because D provides a more complex rule that you can't seem to grasp(but which is very simple and no other human that has used D has had issues with) you say that D is wrong rather than that you or C++ is wrong. The fact is, you are a moron. It's not because of this one issue but because of your mentality of which this is just an example. I'm sure you have the same thing with many issues in your life and you go strutting around like you own the place telling everyone what is wrong with how things are done when you yourself have no clue. Want me to prove it to you? You say: "I feel you should be able to make a member of a class, private, regardless of where the class is located. This seems to break the concept of class encapsulation. " Yet, really, what you mean is that it breaks the concept of class that you learned in programming 101 that had to do with C++. You don't have a clue about logic and qualification. Maybe you are confused and you thought D was C++? You know, if you go to Rome... ah never mind, you won't get it...
Re: how to make private class member private
On Saturday, 17 March 2018 at 21:33:01 UTC, Adam D. Ruppe wrote: On Saturday, 17 March 2018 at 21:22:44 UTC, arturg wrote: maybe extend that to a list of types? this is basically what C++ friend does and D was trying to avoid the complexity of Really, the complexity of 'friend' comes from people abusing it. In D, I would prefer no breaking change here. Leave private as it is. Just a simple attribute that only applies within a class, and only to private members within that class. @strictly private string firstName_; Nothing outside of the class, not even the module, can access this now. It's all encapsulated. It breaks nothing (AFAIK). It's very clear what the intention is here. It's an easy attribute to remember. It restores the principle of class enscapsulation within a module, for when it's really needed. Now D programmers would have the best of both worlds.
Re: how to make private class member private
On Saturday, 17 March 2018 at 21:22:44 UTC, arturg wrote: maybe extend that to a list of types? this is basically what C++ friend does and D was trying to avoid the complexity of
Re: how to make private class member private
On Saturday, 17 March 2018 at 14:16:19 UTC, bauss wrote: I don't like the name @deny, personally I would rather see the private attribute changed to something like: private(true) // The member is oly visible to its parent. private(false) // Same as just "private", visible to whole module. Could be specialized to something like: private(this) // Same as private(true) private(module) // Same as private(false) maybe extend that to a list of types? private(typeof(this), Foo, Bar) would mean only typeof(this), Foo and Bar from the same module have access.
Re: how to make private class member private
On Saturday, 17 March 2018 at 15:02:21 UTC, psychoticRabbit wrote: On Saturday, 17 March 2018 at 14:16:19 UTC, bauss wrote: I don't like the name @deny . how about: @reallyis private string firstName_; mmm..perhaps not... then how about... @strictly private string firstName_; Still introduces a new attribute. D already has a lot of attributes and it goes against how every other attribute for visibility works. That's why my suggestion would work better, because the package attribute already works like that.
Re: how to make private class member private
On Saturday, 17 March 2018 at 14:16:19 UTC, bauss wrote: I don't like the name @deny . how about: @reallyis private string firstName_; mmm..perhaps not... then how about... @strictly private string firstName_;
Re: how to make private class member private
On Saturday, 17 March 2018 at 11:08:27 UTC, psychoticRabbit wrote: On Saturday, 17 March 2018 at 09:18:13 UTC, Nick Treleaven wrote: It's a language design decision as to whether a particular feature is worth supporting. I would like this feature too though. I'm not sure how much compiler complexity would be added by having another visibility modifier. D could add an new attribute to class members: @deny A @deny attribute can come before a classes private member, to indicate that the private member is to remain private, even within the module. Cause sure, it nice to be among friends, but you don't want your friends knowing every thought that is going through your mind! Sometimes, somethings, just need to remain private. @deny private string _userName; now... _userName is no longer accessible at the module level, and class encapsulation is restored. If had I any clue about compilers, I'd think this through more ;-) I don't like the name @deny, personally I would rather see the private attribute changed to something like: private(true) // The member is oly visible to its parent. private(false) // Same as just "private", visible to whole module. Could be specialized to something like: private(this) // Same as private(true) private(module) // Same as private(false) That way it can be introduced without breaking changes and looks cleaner since it wouldn't be yet another attribute. Really it's just an extension to the already existing attribute. This feature should be relatively easy to implement since it's similar to the "package" attribute, which also takes a value as the module name.
Re: how to make private class member private
On Saturday, 17 March 2018 at 09:18:13 UTC, Nick Treleaven wrote: It's a language design decision as to whether a particular feature is worth supporting. I would like this feature too though. I'm not sure how much compiler complexity would be added by having another visibility modifier. D could add an new attribute to class members: @deny A @deny attribute can come before a classes private member, to indicate that the private member is to remain private, even within the module. Cause sure, it nice to be among friends, but you don't want your friends knowing every thought that is going through your mind! Sometimes, somethings, just need to remain private. @deny private string _userName; now... _userName is no longer accessible at the module level, and class encapsulation is restored. If had I any clue about compilers, I'd think this through more ;-)
Re: how to make private class member private
On Tuesday, 13 March 2018 at 13:59:00 UTC, Steven Schveighoffer wrote: If you limit to class members, then you have to do something like C++ friends, which are unnecessarily verbose. Not if you also have a module-level visibility modifier, which could have been `module`. IMO, the module-level encapsulation is the right choice. It helps with a lot of key features: 1. IFTI factory methods Aren't these mainly because constructors can't use IFTI, unlike C++17, and because nullary struct constructors are banned? 2. unittests Documented unittests should not be allowed to use private symbols, I just filed this: https://issues.dlang.org/show_bug.cgi?id=18623
Re: how to make private class member private
On Tuesday, 13 March 2018 at 05:11:48 UTC, psychoticRabbit wrote: If you have access to the module source, you have access to the source of types inside it. Making the module the lowest level of encapsulation makes sense from that perspective. There are two problems I see: 1st - D has broken the concept of class encapsulation, simply for convenience at the module level. Not good in my opinion. It's a language design decision as to whether a particular feature is worth supporting. I would like this feature too though. I'm not sure how much compiler complexity would be added by having another visibility modifier. I'm surprised how many people here ignore the advantage of being able to modify your class/struct fields without the chance of breaking template code that might not even be instantiated by a unit test. (And no, the answer to this isn't fix your tests, because if that's your attitude, why bother with static typing, just use duck typing, the unit tests will catch any bugs). In theory this and other generic unit test issues could be comprehensively solved by having a Rust-like traits feature. 2nd - C++/C#/Java programmers will come to D, use the same syntax, but get very different semantics. Not good in my opinion. (i.e. I only realised private was not private, by accident). D has made many good design decisions. I do not see this as one of them. +1, D should have used a different keyword, such as `module`. It is a classic source of confusion for programmers familiar with many statically typed languages, and it comes up regularly here. It is a syntax issue, semantically the feature is better than just having true private.
Re: how to make private class member private
On Tuesday, 13 March 2018 at 22:56:31 UTC, Jonathan M Davis wrote: The downside is that it increases the number of symbols which the program has to deal with when linking against a shared library, which can have some negative effects. - Jonathan M Davis If I understand correctly it's also responsible for TypeInfo being generated for private classes regardless of whether or not it is ever used.
Re: how to make private class member private
On Wednesday, 14 March 2018 at 04:30:17 UTC, Amorphorious wrote: On Wednesday, 14 March 2018 at 01:41:33 UTC, psychoticRabbit wrote: On Tuesday, 13 March 2018 at 21:38:59 UTC, Amorphorious wrote: You are a moron...etc..etc..etc..etc. See. This is what happens when you have access to a keyboard while high on ice. Yep. So maybe you should stop doing the ice?!?! Then maybe you could actually reply with an intelligent answer? How old are you, BTW? 15? You know that at that age ice is pretty bad for you. It will drop your IQ 20 points in a year, so since you obviously have an IQ of 60 then means you've been doing ice for about 1 year now... better stop while you have any brain cell's left. Please refrain from personal attacks! The forum should be a place people enjoy to be and can have professional discussion.
Re: how to make private class member private
On Wednesday, 14 March 2018 at 01:41:33 UTC, psychoticRabbit wrote: On Tuesday, 13 March 2018 at 21:38:59 UTC, Amorphorious wrote: You are a moron...etc..etc..etc..etc. See. This is what happens when you have access to a keyboard while high on ice. Yep. So maybe you should stop doing the ice?!?! Then maybe you could actually reply with an intelligent answer? How old are you, BTW? 15? You know that at that age ice is pretty bad for you. It will drop your IQ 20 points in a year, so since you obviously have an IQ of 60 then means you've been doing ice for about 1 year now... better stop while you have any brain cell's left.
Re: how to make private class member private
On Tuesday, 13 March 2018 at 21:38:59 UTC, Amorphorious wrote: You are a moron...etc..etc..etc..etc. See. This is what happens when you have access to a keyboard while high on ice.
Re: how to make private class member private
On Tuesday, March 13, 2018 22:25:52 Nathan S. via Digitalmars-d-learn wrote: > On Tuesday, 13 March 2018 at 21:36:13 UTC, Arun Chandrasekaran > > wrote: > > On Tuesday, 13 March 2018 at 13:59:00 UTC, Steven Schveighoffer > > > > wrote: > >> On 3/12/18 10:06 PM, psychoticRabbit wrote: > >>> [...] > >> > >> OK, so I agree there are drawbacks. But these can be worked > >> around. > >> > >> [...] > > > > Private members still have external linkage. Is there anyway to > > solve this? > > Yeah that's a real WTF. It's how linking is normally done on Linux with C/C++ and has the advantage of not having to mark any functions as being external like you have to do on Windows. Personally, I've always found having to deal with that with C/C++ on Windows to be extremely annoying, whereas on Linux, shared libraries just work. So, from a usability perspective, I can't say that I'm at all pleased at the idea of having to mark anything as having external linkage in D. The downside is that it increases the number of symbols which the program has to deal with when linking against a shared library, which can have some negative effects. - Jonathan M Davis
Re: how to make private class member private
On Tuesday, 13 March 2018 at 21:36:13 UTC, Arun Chandrasekaran wrote: On Tuesday, 13 March 2018 at 13:59:00 UTC, Steven Schveighoffer wrote: On 3/12/18 10:06 PM, psychoticRabbit wrote: [...] OK, so I agree there are drawbacks. But these can be worked around. [...] Private members still have external linkage. Is there anyway to solve this? Yeah that's a real WTF.
Re: how to make private class member private
On Tuesday, March 13, 2018 21:36:13 Arun Chandrasekaran via Digitalmars-d- learn wrote: > On Tuesday, 13 March 2018 at 13:59:00 UTC, Steven Schveighoffer > > wrote: > > On 3/12/18 10:06 PM, psychoticRabbit wrote: > >> [...] > > > > OK, so I agree there are drawbacks. But these can be worked > > around. > > > > [...] > > Private members still have external linkage. Is there anyway to > solve this? No. There are some folks who want to change it so that you have to use extern to have external linkage, but all of that is a work in progress and would have to be approved by Walter. - Jonathan M Davis
Re: how to make private class member private
On Tuesday, 13 March 2018 at 09:14:26 UTC, psychoticRabbit wrote: what I don't like, is that I have no way at all to protect members of my class, from things in the module, without moving that class out of that module. D wants me to completely trust the module, no matter what. That's make a little uncomfortable, given how long and complex modules can easily become(and aleady are) I used to feel similarly and understand where you're coming from but after using D for a while the old way feels ridiculous and cumbersome to me. The problem of accidents even in large files can be avoided by using names like "m_length" or "_length": no jury in the world will believe you if you write those then say you didn't know they were private.
Re: how to make private class member private
On Tuesday, 13 March 2018 at 06:10:26 UTC, psychoticRabbit wrote: On Tuesday, 13 March 2018 at 05:35:30 UTC, Amorphorious wrote: There is another problem: 3rd: You are a brainwashed monkey who can't think for himself. Gee..takes some real brains to come up with that one. See, You learned a little about C++/C#/Java and think the world must conform to what they say is correct and deny everything that contradicts it rather than first seeing if you are on the wrong side of the contradiction. The fact is, there is no reason a module should be restricted to see it's own classes private members. Yeah that sounds fine. As long as you're willing to give up the concept of class encapsulation. And, as long as you are willing to have programmers use the same syntax in D, as used in the 3 most widely used lanaguages on the planet, but get very different semantics. It's a real gotcha for those programmers. It's sorta like a family who runs around pretending that they can't see each others private parts. Sure, it sounds like a good thing... until someone accidentally drops the towel and the offended calls the cop on their brother and has him arrested for breaking the law. I'm not interested in your fanatasies. Keep them to yourself. You should learn that your view of the world is very minute and stop trying to fit the world in to your box. It's called growing up. If you can't make a distinction between C++ encapsulation and D encapsulation you have far bigger problems than you think. I think the view of the 3 most widely used langauges on the planet, is not something to dismiss so easily. D has what, 1000 programmers, maybe.. so I wonder whose world is really minute. In any case, I'm not attacking D. I use it. I am just questioning whether the different semantics for private, in D, is really worth it. You are a moron. That is the simple issue. That is why you get confused easily and why you have trouble. I am stating this not as a ad hominem but as the truth. You lack the reasoning ability to realize that the world is vastly different than what goes on in your pea sized brain(that is a personal attack, unless one is using pea as a metaphor for your lack of experience in the real world to teach you that things don't always follow linear lines). 1. EVEN IF THE TOP 1 MILLION PROGRAMMING LANGUAGES ALL USED THE EXACT SAME SYNTAX, SAME COMPILER, SAME FORUMS, SAME WHATEVER, it means NOTHING! Truth isn't dictated by numbers. You surely are a believer in Christianity or Islam? This type of "logic" is what they typically use. a. You'd see that all those 1M PL's are identical, so, in fact, there is just 1. In fact, one could say inflate all programming languages by saying there are N copies. e.g., D actually has 1 Billion versions all identical. Don't believe me, just make 1 Billion copies on your 4TB HD(ok, it will take about 10PB, so what). If you want, write a self-modifying compiler that modifies the source a bit to change random non-breaking changes. That way you actually have 1 Billion different copies... just so you can be pedantic. b. God didn't write "Classes must be self-encapsulated" in the 10 commandments... hence it is false to assume they must. After all, if God wanted it, it would be so. 2. Being a lemming makes this very hard for you to grasp... but ask yourself why Haskell is different, after all, it didn't conform to C/C++... so it must be wrong too. 3. Why aren't people running around living in caves? After all, the first humans started doing that! In fact, why don't all humans live in the sea? After all, the real first humans did that. Your logic is that the first dictates what the last should be... and the only reason is because your pathetic brain can't grasp the fact that there is no law that requires that. It's no different than saying that the son of a blacksmith must be a blacksmith, but again, your inability to abstract will find this very hard to understand. Let me put it different, Is a son of a bitch a bitch? Oh, does that make more sense? No? Oh well, I tried... The fact is, you are clueless on some level if you really think you are right. The fact that you would waste your time and everyone around you arguing some useless point that means nothing is pointless... which goes to show that you are not that intelligent. The goal, here, is to try to fix whatever bug is in your brain that prevents you from becoming more intelligent. Only time will tell if it works... I'm sorry for wasting your time. I'm sure you have better things to do like go argue why Hans Solo should have wore a blue vest instead of a black one because it's the colors of his heraldry and Lucas was wrong for putting him in black. Or maybe today it you were going to argue that Harry Potters wand should be made out of Ceder because all wizards use Ceder. Or maybe it is something else?
Re: how to make private class member private
On Tuesday, 13 March 2018 at 13:59:00 UTC, Steven Schveighoffer wrote: On 3/12/18 10:06 PM, psychoticRabbit wrote: [...] OK, so I agree there are drawbacks. But these can be worked around. [...] Private members still have external linkage. Is there anyway to solve this?
Re: how to make private class member private
On Tuesday, 13 March 2018 at 02:06:57 UTC, psychoticRabbit wrote: On Tuesday, 13 March 2018 at 01:39:13 UTC, Jonathan M Davis wrote: private is private to the module, not the class. There is no way in D to restrict the rest of the module from accessing the members of a class. This simplification makes it so that stuff like C++'s friend are unnecessary. If your class in a separate module from main, then main won't be able to access its private members. - Jonathan M Davis Mmm.. I don't think I like it. I feel you should be able to make a member of a class, private, regardless of where the class is located. This seems to break the concept of class encapsulation. No. I don't like it at all. Relevant article: http://www.drdobbs.com/cpp/how-non-member-functions-improve-encapsu/184401197
Re: how to make private class member private
On 3/12/18 10:06 PM, psychoticRabbit wrote: On Tuesday, 13 March 2018 at 01:39:13 UTC, Jonathan M Davis wrote: private is private to the module, not the class. There is no way in D to restrict the rest of the module from accessing the members of a class. This simplification makes it so that stuff like C++'s friend are unnecessary. If your class in a separate module from main, then main won't be able to access its private members. - Jonathan M Davis Mmm.. I don't think I like it. I feel you should be able to make a member of a class, private, regardless of where the class is located. This seems to break the concept of class encapsulation. No. I don't like it at all. OK, so I agree there are drawbacks. But these can be worked around. In fact, the language author touted this article as sage advice, when in D it's pretty inconvenient: https://forum.dlang.org/post/osr2l3$1ihb$2...@digitalmars.com But when you get right down to it, where you draw the line is arbitrary. Given the power to encapsulate on module boundary, you have lots of different options as to where your functions can reach. You can pretty much put anything into a module, so you aren't limited to class members which can access specific data. With the advent of package modules, you can control quite finely what functions have access to what items, and still have nice simple imports. If you limit to class members, then you have to do something like C++ friends, which are unnecessarily verbose. IMO, the module-level encapsulation is the right choice. It helps with a lot of key features: 1. IFTI factory methods 2. unittests 3. co-related structs/classes -Steve
Re: how to make private class member private
On Tuesday, March 13, 2018 02:06:57 psychoticRabbit via Digitalmars-d-learn wrote: > On Tuesday, 13 March 2018 at 01:39:13 UTC, Jonathan M Davis wrote: > > private is private to the module, not the class. There is no > > way in D to restrict the rest of the module from accessing the > > members of a class. This simplification makes it so that stuff > > like C++'s friend are unnecessary. If your class in a separate > > module from main, then main won't be able to access its private > > members. > > > > - Jonathan M Davis > > Mmm.. I don't think I like it. > > I feel you should be able to make a member of a class, private, > regardless of where the class is located. This seems to break the > concept of class encapsulation. > > No. I don't like it at all. Well, this thread sure blew up fast... The decision to make private restrict access to the module certainly has pros and cons, but it works well over all. C++'s solution using friend is more flexible, but it's also more complicated. D's solution removes that extra complication. It also makes the use of private throughout the module more consistent, since unlike C++, D has modules and has to worry about the access level of symbols within a module and not just within classes. Also, given D's built-in unit testing features, being able to have unittest blocks within the module access anything within the module makes testing much easier. No one has to muck with access levels to make stuff available to unit tests as is often the case with languages like Java. And while it might initially seem annoying that you can't restrict access of a member to a class or struct even within a module, it's something that most of us have found to not be a problem in practice. But as with all design decisions, there are tradeoffs, and different people have different opinions about which tradeoffs make the most sense. The only case I'm aware of where I'd consider the current design to be a problem is that if all of your testing is done within the module, it's harder to catch cases where you screwed up the access level and made something private when you didn't mean to. Being able to access all of the private stuff for tests can be extremely useful, so it's certainly not the case that simply making it so that unittest blocks had only public or package access would be a clear improvement, but it's also not the case that the current design doesn't come with any downsides. If you really want to restrict access to the class itself, then you can always just declare a class in its own module just like Java forces you to do. That might be annoying if want to put several classes in the same module while restricting their access, but it is a way to enforce full encapsulation if that's what you really want. Ultimately though, for better or worse, D considers the module to be the primary unit of encapsulation in the language, and most of us find that it works quite well. Given time you may find that you don't mind it as much - or not, but that's the way that D does it, and I very much doubt that that's ever going to change. - Jonathan M Davis
Re: how to make private class member private
On Tuesday, 13 March 2018 at 13:08:44 UTC, psychoticRabbit wrote: It also means the author of the class is no longer free to make changes, because all the surrounding code in the module needs to be assessed for impact - this greatly increases the burden of program correctness and maintenance. The author of the class could just put it in a separate file. As is required by Java and a frequent convention in C++ in C# anyway. If you can't put it in a separate file, it isn't as encapsulated as you think anyway!
Re: how to make private class member private
On Tuesday, 13 March 2018 at 08:44:48 UTC, Mike Parker wrote: Making modules the lowest level of encapsulation does that without the need for an extra keyword for friends while still maintaining a strict border between external and internal APIs. Moreover, it restricts friends to the same module, easing the maintenance burden and decreasing the chance of error. It was a great decision. Actually I wonder if it's the opposite of that, because now, if I have a bug in my class implementation, the code is no longer localised to the class, but to the module - this greatly increases the burden of program correctness and maintenance. It also means the author of the class is no longer free to make changes, because all the surrounding code in the module needs to be assessed for impact - this greatly increases the burden of program correctness and maintenance.
Re: how to make private class member private
On Tuesday, 13 March 2018 at 12:10:07 UTC, rikki cattermole wrote: On 14/03/2018 1:02 AM, psychoticRabbit wrote: On Tuesday, 13 March 2018 at 11:31:12 UTC, rikki cattermole wrote: Ah yes. You're completely correct if you subscribe to Adam's and ketmar's file sizes expectation. A D module and package is one level of abstraction. If that level of abstraction starts to fill up and gets large, you split it up. My rule is soft 1k LOC and hard 2-3k (after that it needs a VERY good reason to stay together). This makes each file to be very right down to the point and do nothing else. You should be doing this no matter the language IMO. Just the difference is in Java only one class is publicly accessible per file. Nothing stops you from doing that here either. Fair enough. I doubt I'll use your 'lines of code' method as a means of encapsulation though ;-) The number of lines of code is more of a code smell which suggests that the module is going out of scope in size and functionality. I have to think more, about what a module is really trying to encapsulate. I'm sure there is a good blog that could come out of this conversation. (not by me though) While it is new to some people, we would only be rehashing existing ideas that have existed in the literature for 40+ years. Mmm...I think more than just 'some people' will be suprised when they come to D, and suddenly find that a private member may not be private at all. Particulary those C++/C#/Java programmers - who represent the vast majority of programmers on the planet. private string _Name; (oh..in D, this might be private..or it might not be..depends on what you mean by private)
Re: how to make private class member private
On 14/03/2018 1:02 AM, psychoticRabbit wrote: On Tuesday, 13 March 2018 at 11:31:12 UTC, rikki cattermole wrote: Ah yes. You're completely correct if you subscribe to Adam's and ketmar's file sizes expectation. A D module and package is one level of abstraction. If that level of abstraction starts to fill up and gets large, you split it up. My rule is soft 1k LOC and hard 2-3k (after that it needs a VERY good reason to stay together). This makes each file to be very right down to the point and do nothing else. You should be doing this no matter the language IMO. Just the difference is in Java only one class is publicly accessible per file. Nothing stops you from doing that here either. Fair enough. I doubt I'll use your 'lines of code' method as a means of encapsulation though ;-) The number of lines of code is more of a code smell which suggests that the module is going out of scope in size and functionality. I have to think more, about what a module is really trying to encapsulate. I'm sure there is a good blog that could come out of this conversation. (not by me though) While it is new to some people, we would only be rehashing existing ideas that have existed in the literature for 40+ years.
Re: how to make private class member private
On Tuesday, 13 March 2018 at 11:31:12 UTC, rikki cattermole wrote: Ah yes. You're completely correct if you subscribe to Adam's and ketmar's file sizes expectation. A D module and package is one level of abstraction. If that level of abstraction starts to fill up and gets large, you split it up. My rule is soft 1k LOC and hard 2-3k (after that it needs a VERY good reason to stay together). This makes each file to be very right down to the point and do nothing else. You should be doing this no matter the language IMO. Just the difference is in Java only one class is publicly accessible per file. Nothing stops you from doing that here either. Fair enough. I doubt I'll use your 'lines of code' method as a means of encapsulation though ;-) I have to think more, about what a module is really trying to encapsulate. I'm sure there is a good blog that could come out of this conversation. (not by me though)
Re: how to make private class member private
On 14/03/2018 12:19 AM, psychoticRabbit wrote:
On Tuesday, 13 March 2018 at 08:29:42 UTC, Alex wrote:
package myPackage;
public class Main {
public static void main(String[] args)
{
System.out.println("Hello World!");
myClass c = new myClass();
c.myPrivateClassMember= "wtf";
System.out.println(c.myPrivateClassMember);
}
private static class myClass
{
private String myPrivateClassMember; // private does not mean
private anymore??
}
}
´´´
(may the forum forgive me :p )
But a class and its inner classes together, can be still be reasoned
about locally.
With 'modules', the boundaries of what 'local' means, becomes more and
more fuzzy, as the module gets longer and longer, and more and more
complex.
In those circumstances, it becomes much harder to reason locally about
the correctness of a class.
And a D module can go on..well...for ever.
I would still prefer that classes within a module, at least have a
capacity to specify access privileges to objects in the same module,
rather than just trusting everything in that module, without exception.
Ah yes.
You're completely correct if you subscribe to Adam's and ketmar's file
sizes expectation.
A D module and package is one level of abstraction. If that level of
abstraction starts to fill up and gets large, you split it up.
My rule is soft 1k LOC and hard 2-3k (after that it needs a VERY good
reason to stay together).
This makes each file to be very right down to the point and do nothing else.
You should be doing this no matter the language IMO. Just the difference
is in Java only one class is publicly accessible per file. Nothing stops
you from doing that here either.
Re: how to make private class member private
On Tuesday, 13 March 2018 at 08:44:48 UTC, Mike Parker wrote: Moreover, it restricts friends to the same module, easing the maintenance burden and decreasing the chance of error. It was a great decision. But, a module can contain so many 'friends'. Q. How many 'friends' does it take, before you lose the capacity to reason about who really is a friend?
Re: how to make private class member private
On Tuesday, 13 March 2018 at 08:29:42 UTC, Alex wrote:
package myPackage;
public class Main {
public static void main(String[] args)
{
System.out.println("Hello World!");
myClass c = new myClass();
c.myPrivateClassMember= "wtf";
System.out.println(c.myPrivateClassMember);
}
private static class myClass
{
private String myPrivateClassMember; // private does
not mean private anymore??
}
}
´´´
(may the forum forgive me :p )
But a class and its inner classes together, can be still be
reasoned about locally.
With 'modules', the boundaries of what 'local' means, becomes
more and more fuzzy, as the module gets longer and longer, and
more and more complex.
In those circumstances, it becomes much harder to reason locally
about the correctness of a class.
And a D module can go on..well...for ever.
I would still prefer that classes within a module, at least have
a capacity to specify access privileges to objects in the same
module, rather than just trusting everything in that module,
without exception.
Re: how to make private class member private
On Tuesday, 13 March 2018 at 09:52:06 UTC, Mike Parker wrote: On Tuesday, 13 March 2018 at 09:14:26 UTC, psychoticRabbit wrote: That's make a little uncomfortable, given how long and complex modules can easily become(and aleady are) Is there a practical difference between a) a module that contains a class with 20 member functions all accessing private members of the class and b) a module that contains a class with two member functions and 18 free functions all accessing private members of the class? Does it really make a difference that some functions are on one side of a closing brace and some on the other? The scenario you mentioned is fine, as long as I don't want to protect any of my class members from free functions within the module. When I do decide that something in my class really does need protection, I have to move the class outside of the module. This concept is new to me. I have to keep thinking about it. To lose control at the level of class encapsulation, and surrender it completely to the module, no matter what..well..I'm a little unsure about it. I'd be more comfortable with being able to have your scenario and mine 'both work'. At what point, does 'principled' violation of encapsulation, just become a violation of encapsulation?
Re: how to make private class member private
On Tuesday, 13 March 2018 at 09:14:26 UTC, psychoticRabbit wrote: That's make a little uncomfortable, given how long and complex modules can easily become(and aleady are) Is there a practical difference between a) a module that contains a class with 20 member functions all accessing private members of the class and b) a module that contains a class with two member functions and 18 free functions all accessing private members of the class? Does it really make a difference that some functions are on one side of a closing brace and some on the other?
Re: how to make private class member private
On Tuesday, 13 March 2018 at 08:44:48 UTC, Mike Parker wrote: Any new keywords, or reuse of existing keywords, does make the language more complex. Everything that is added must have a reason. Private is module level because friend is so common in C++, i.e. people find it useful and it would be great to support something similar in D. Making modules the lowest level of encapsulation does that without the need for an extra keyword for friends while still maintaining a strict border between external and internal APIs. Moreover, it restricts friends to the same module, easing the maintenance burden and decreasing the chance of error. It was a great decision. yeah, I probably agree that it's a good decision, when the module is the boundary. (aka so-called 'principled' violation of encapsulation) what I don't like, is that I have no way at all to protect members of my class, from things in the module, without moving that class out of that module. D wants me to completely trust the module, no matter what. That's make a little uncomfortable, given how long and complex modules can easily become(and aleady are)
Re: how to make private class member private
On Tuesday, 13 March 2018 at 06:58:08 UTC, psychoticRabbit wrote: What you're saying, is in D, class encapsulation is really 'module' encapsulation. I get it. Fine. It's an intersting design decision. "Enapsulation" in D means the same as it does in every other language -- hidden from the outside. The purpose of encapsulation is to prevent client code from breaking when an internal API changes. That's exactly the level of encapsulation that D's private provides. Making private restrict access to the class would be like other languages, sure, but then it becomes over restrictive. But, in doing that, D has shifted the boundary of class encapsulation, to a boundary that is outside the class. Nope. It's still hidden from the outside world. No one can read or write private class members *from the external API*. To me, that sounds like D has broken class encapsulation. I don't know how else one could describe it. I continue to think, that class encapsulation is sacred, a well defined, well understood, concept that has been around for a very long time. Only if you view encapsulation as something other than "hidden from the outside world". private could have still meant private, and surely someone could have come up with a different access modifier to mean 'private at module level'. Was that too hard the language designers? Was it not hard, but just to complex to implement? I don't get it. Any new keywords, or reuse of existing keywords, does make the language more complex. Everything that is added must have a reason. Private is module level because friend is so common in C++, i.e. people find it useful and it would be great to support something similar in D. Making modules the lowest level of encapsulation does that without the need for an extra keyword for friends while still maintaining a strict border between external and internal APIs. Moreover, it restricts friends to the same module, easing the maintenance burden and decreasing the chance of error. It was a great decision.
Re: how to make private class member private
On Tuesday, 13 March 2018 at 08:05:43 UTC, psychoticRabbit wrote: On Tuesday, 13 March 2018 at 06:03:11 UTC, Mike Parker wrote: I think it's a great feature and I use it frequently. It's allows more flexibility in class design. Without it, we'd need another protection attribute to enable the concept of "private to the module". what about a new access attribute (and no, I haven't though this through much): owned string _FirstName; (now the class 'owns' this. It is neither readable nor writeable outside the boundary of that class. This retains the existing flexibilty offered by module level encapsulation, while restoring class level encapsulation/ownership. or another idea: ownedBy T string _FirstName; where T could be 'Module' (meaning it works the way it currently does. The module can read/write to it). or T could 'Universe' (where universe means everyone can do whatever they want with it). or T could be 'This'(so class can regain control overs its own members), The default could be ownedBy Module, to retain existing behaviour. I'd even go further, with extended attributes... ownedBy Module Read string _FirstName; ownedBy Module Write string _FirstName; ownedBy Module ReadWrite string _FirstName;
Re: how to make private class member private
On Tuesday, 13 March 2018 at 07:39:04 UTC, psychoticRabbit wrote:
I don't have any objection to the idea that a module can have
privileged access to members of classes within that model. It
sounds sensible enough, if the module is a level of
encapsulation also.
My arguments is that, this was implemented in D, at the cost of
removing the capacity for a class in the same module to protect
it's own members (within the module). That's what I don't like
about it.
My other objection, as stated, is that D uses the same syntax
as C++/C#/Java, but the semantics of that same syntax are
completely different. I also don't like that.
If you are missing more fine grained encapsulation control: take
a look at
https://wiki.dlang.org/Access_specifiers_and_visibility#package
If you are in debt, that encapsulation at module level is more
superior with respect to encapsulation and expressiveness in
comparison to class level, look at Fortran and Java 9.
And last but not least:
´´´
package myPackage;
public class Main {
public static void main(String[] args)
{
System.out.println("Hello World!");
myClass c = new myClass();
c.myPrivateClassMember= "wtf";
System.out.println(c.myPrivateClassMember);
}
private static class myClass
{
private String myPrivateClassMember; // private does not
mean private anymore??
}
}
´´´
(may the forum forgive me :p )
Re: how to make private class member private
On Tuesday, 13 March 2018 at 08:05:43 UTC, psychoticRabbit wrote:
On Tuesday, 13 March 2018 at 06:03:11 UTC, Mike Parker wrote:
I think it's a great feature and I use it frequently. It's
allows more flexibility in class design. Without it, we'd need
another protection attribute to enable the concept of "private
to the module".
what about a new access attribute (and no, I haven't though
this through much):
owned string _FirstName;
(now the class 'owns' this.
It is neither readable nor writeable outside the boundary of
that class.
This retains the existing flexibilty offered by module level
encapsulation, while restoring class level
encapsulation/ownership.
So, what's wrong with this?
===
module foo;
class Blah
{
public int pub;
private int priv;
}
===
module bar;
import foo;
void main()
{
auto c = new Blah();
c.priv = 42; // compile error
}
===
You can still code like Java, one file per class (module) and
keep those private members protection across modules classes.
What's different with D is that the scope is the module not the
class (package), and this is good. This is a trade-of, usually
one codes related components in a module, thus frequently needs
access to those components inside the module. You can have class,
struct, functions, enums, static variables and templates in the
same module, and pragmatically you will need to access private
data on them. You still have the private to signal the intent,
just that the philosophy is different when looking at the basic
compilation unit.
Re: how to make private class member private
On Tuesday, 13 March 2018 at 06:58:08 UTC, psychoticRabbit wrote: On Tuesday, 13 March 2018 at 06:03:11 UTC, Mike Parker wrote: The same applies here. Encapsulation simply isn't broken by this feature. What you're saying, is in D, class encapsulation is really 'module' encapsulation. I get it. Fine. It's an intersting design decision. But, in doing that, D has shifted the boundary of class encapsulation, to a boundary that is outside the class. To me, that sounds like D has broken class encapsulation. I don't know how else one could describe it. I continue to think, that class encapsulation is sacred, a well defined, well understood, concept that has been around for a very long time. private could have still meant private, and surely someone could have come up with a different access modifier to mean 'private at module level'. Was that too hard the language designers? Was it not hard, but just to complex to implement? I don't get it. I agree that class encapsulation is broken, well, not broken but just not a thing really. Don't think it's a bad thing though. Case in point, swift had private as file level access, swift 3 they introduced fileprivate [0] to do that instead and had private be scope level (which includes class level and is what you're referring to private being). Swift 4 they reverted it kinda [1] It was too inconvenient to not allow access to private members within a file in a language that allows extensions (think ufcs). So they compromised a bit here and went for decleration level which makes sense within their extension semantics. This would not work for D thought because ufcs is not really a type extension (i.e. not part of a type's typeinfo) So now the difference is that private can be used in a file but only in a declaration and fileprivate can be used anywhere in a file. So they allow class encapsulation but at a file level. It's an interesting approach and quite neat. Rust is also the same as D I believe. Module is the unit of encapsulation. I wouldn't want private to change it's meaning quite frankly in the module system. I would not mind more control within a module though because, well, encapsulation. A Rust-ish approach were you can define a path [2] might allow for a lot more freedom but I'm not sure how well that would work with D. Cheers [0] https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md [1] https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md [2] https://doc.rust-lang.org/beta/reference/visibility-and-privacy.html
Re: how to make private class member private
psychoticRabbit wrote: Whatever happened to the 'discussion' component of these 'discussions'? dunno. try to ask yourself, why repeating the same point again and again when you were given the answer and the rationale doesn't make a good discussion.
Re: how to make private class member private
On Tuesday, 13 March 2018 at 06:03:11 UTC, Mike Parker wrote: I think it's a great feature and I use it frequently. It's allows more flexibility in class design. Without it, we'd need another protection attribute to enable the concept of "private to the module". what about a new access attribute (and no, I haven't though this through much): owned string _FirstName; (now the class 'owns' this. It is neither readable nor writeable outside the boundary of that class. This retains the existing flexibilty offered by module level encapsulation, while restoring class level encapsulation/ownership.
Re: how to make private class member private
On Tuesday, 13 March 2018 at 07:05:48 UTC, rikki cattermole wrote: Your thought model is much younger than modules. Modules have existed since the mid 70's. They work, other designs over the years have proven to have faults and problems. D's design is evolved from already existing ideas to try and give the best of both worlds and modules is no different. The reality is, Java and C++ both are great examples where module system was added after many years too late. D had it built in from the get go and was designed to benefit from it. I don't have any objection to the idea that a module can have privileged access to members of classes within that model. It sounds sensible enough, if the module is a level of encapsulation also. My arguments is that, this was implemented in D, at the cost of removing the capacity for a class in the same module to protect it's own members (within the module). That's what I don't like about it. My other objection, as stated, is that D uses the same syntax as C++/C#/Java, but the semantics of that same syntax are completely different. I also don't like that.
Re: how to make private class member private
On Tuesday, 13 March 2018 at 06:43:55 UTC, ketmar wrote: that is, we should stick to defective design only 'cause there is no "other D" that made it right? ;-) also, your question is not valid. you were told several times that you're evaluating the whole thing wrong, but you're insisting on your view being right. and you're keep asking, omiting the *critical* piece of the picture: modules. you were told that in D, encapsulation unit is *module*, not class/struct. it is not a "misdesign", it is the proper modular design. it doesn't matter what others are doing in this case. p.s.: yes, i know such language. Delphi/FreePascal. Gee.. I feel like I'm on a Rust forum, being attacked my their sjw moderators. Whatever happened to the 'discussion' component of these 'discussions'?
Re: how to make private class member private
Your thought model is much younger than modules. Modules have existed since the mid 70's. They work, other designs over the years have proven to have faults and problems. D's design is evolved from already existing ideas to try and give the best of both worlds and modules is no different. The reality is, Java and C++ both are great examples where module system was added after many years too late. D had it built in from the get go and was designed to benefit from it.
Re: how to make private class member private
On Tuesday, 13 March 2018 at 06:03:11 UTC, Mike Parker wrote: The same applies here. Encapsulation simply isn't broken by this feature. What you're saying, is in D, class encapsulation is really 'module' encapsulation. I get it. Fine. It's an intersting design decision. But, in doing that, D has shifted the boundary of class encapsulation, to a boundary that is outside the class. To me, that sounds like D has broken class encapsulation. I don't know how else one could describe it. I continue to think, that class encapsulation is sacred, a well defined, well understood, concept that has been around for a very long time. private could have still meant private, and surely someone could have come up with a different access modifier to mean 'private at module level'. Was that too hard the language designers? Was it not hard, but just to complex to implement? I don't get it.
Re: how to make private class member private
psychoticRabbit wrote: On Tuesday, 13 March 2018 at 06:25:39 UTC, ketmar wrote: psychoticRabbit wrote: So the 3 most used languages got it wrong?? yes. do you know any other language, where a private class memeber, is not private to the class? (btw. that's a question, not a statement). that is, we should stick to defective design only 'cause there is no "other D" that made it right? ;-) also, your question is not valid. you were told several times that you're evaluating the whole thing wrong, but you're insisting on your view being right. and you're keep asking, omiting the *critical* piece of the picture: modules. you were told that in D, encapsulation unit is *module*, not class/struct. it is not a "misdesign", it is the proper modular design. it doesn't matter what others are doing in this case. p.s.: yes, i know such language. Delphi/FreePascal.
Re: how to make private class member private
On Tuesday, 13 March 2018 at 06:26:13 UTC, Radu wrote: On Tuesday, 13 March 2018 at 06:14:49 UTC, psychoticRabbit wrote: On Tuesday, 13 March 2018 at 06:01:43 UTC, ketmar wrote: ah, yes, sorry: i completely forgot that C++ was invented after c# and java. mea maxima culpa! My point was, that the 2 most widely used and popular languages on the plant, C# and Java, decided NOT to make private, something mean else, like D has done. So the 3 most used languages got it wrong?? Yes, they got it wrong! Because they don't have modules, and because Java & C# are OOP bondage-everything-is-a-class, and preach that the world spins on classes. C++ tried to fix it with 'friend', and it shows the hack that it is. Don't know why you think D should be just another Java or C#? Well I don't really. But one of the great things about D, is that a C++/C#/Java programmers can jump right in. But when the same syntax suddenly means something really different, I tend to think that's not a good design decision. And that's really the main point of my argument. As I said, this was a real gotcha for me. I only realised after I accidently tried to modify a private member directly, and discovered I did actually modify it! Maybe, a different modifier that made it private to the module would have been a better design decision.
Re: how to make private class member private
On 13/03/2018 7:14 PM, psychoticRabbit wrote: On Tuesday, 13 March 2018 at 06:01:43 UTC, ketmar wrote: ah, yes, sorry: i completely forgot that C++ was invented after c# and java. mea maxima culpa! My point was, that the 2 most widely used and popular languages on the plant, C# and Java, decided NOT to make private, something mean else, like D has done. So the 3 most used languages got it wrong?? Yes. Module system comes from the ML family. As proven by the adoption by Java as of late, it is far superior to alternative designs.
Re: how to make private class member private
psychoticRabbit wrote: So the 3 most used languages got it wrong?? yes.
Re: how to make private class member private
On Tuesday, 13 March 2018 at 06:25:39 UTC, ketmar wrote: psychoticRabbit wrote: So the 3 most used languages got it wrong?? yes. do you know any other language, where a private class memeber, is not private to the class? (btw. that's a question, not a statement).
Re: how to make private class member private
On Tuesday, 13 March 2018 at 06:14:49 UTC, psychoticRabbit wrote: On Tuesday, 13 March 2018 at 06:01:43 UTC, ketmar wrote: ah, yes, sorry: i completely forgot that C++ was invented after c# and java. mea maxima culpa! My point was, that the 2 most widely used and popular languages on the plant, C# and Java, decided NOT to make private, something mean else, like D has done. So the 3 most used languages got it wrong?? Yes, they got it wrong! Because they don't have modules, and because Java & C# are OOP bondage-everything-is-a-class, and preach that the world spins on classes. C++ tried to fix it with 'friend', and it shows the hack that it is. Don't know why you think D should be just another Java or C#?
Re: how to make private class member private
On Tuesday, 13 March 2018 at 06:03:11 UTC, Mike Parker wrote: I think it's a great feature and I use it frequently. It's allows more flexibility in class design. Without it, we'd need another protection attribute to enable the concept of "private to the module". That's kind of my point. That's what I would have done, if for no other reason, to prevent the same syntax from having different semantics (when C++/C#/Java programmers come over to D). And I switch between them all, and now, I have to remember D's private memeber is something very different indeed. In Java, it's recommended to manipulate private member variables through their accessors even in methods of the same class. I've always found that extreme. Java is extreme in many ways ;-) but at least, private member, is still a private member (to the class). If my private class memeber can be directly modified outside of the class, then class encapsulation IS broken. Just saying, oh no, it's module encapsulation you should be thinking about, seems kinda strange, since we still use classes - which are their own level of encapsulation. That's the whole point of them.
Re: how to make private class member private
On Tuesday, 13 March 2018 at 05:35:30 UTC, Amorphorious wrote: There is another problem: 3rd: You are a brainwashed monkey who can't think for himself. Gee..takes some real brains to come up with that one. See, You learned a little about C++/C#/Java and think the world must conform to what they say is correct and deny everything that contradicts it rather than first seeing if you are on the wrong side of the contradiction. The fact is, there is no reason a module should be restricted to see it's own classes private members. Yeah that sounds fine. As long as you're willing to give up the concept of class encapsulation. And, as long as you are willing to have programmers use the same syntax in D, as used in the 3 most widely used lanaguages on the planet, but get very different semantics. It's a real gotcha for those programmers. It's sorta like a family who runs around pretending that they can't see each others private parts. Sure, it sounds like a good thing... until someone accidentally drops the towel and the offended calls the cop on their brother and has him arrested for breaking the law. I'm not interested in your fanatasies. Keep them to yourself. You should learn that your view of the world is very minute and stop trying to fit the world in to your box. It's called growing up. If you can't make a distinction between C++ encapsulation and D encapsulation you have far bigger problems than you think. I think the view of the 3 most widely used langauges on the planet, is not something to dismiss so easily. D has what, 1000 programmers, maybe.. so I wonder whose world is really minute. In any case, I'm not attacking D. I use it. I am just questioning whether the different semantics for private, in D, is really worth it.
Re: how to make private class member private
On Tuesday, 13 March 2018 at 06:01:43 UTC, ketmar wrote: ah, yes, sorry: i completely forgot that C++ was invented after c# and java. mea maxima culpa! My point was, that the 2 most widely used and popular languages on the plant, C# and Java, decided NOT to make private, something mean else, like D has done. So the 3 most used languages got it wrong??
Re: how to make private class member private
psychoticRabbit wrote: On Tuesday, 13 March 2018 at 05:52:55 UTC, ketmar wrote: psychoticRabbit wrote: There are two problems I see: 1) it is not how C++ done it. 2) it is not how C++ done it. and you're completely right: it is not how C++ done it. umm...didn't you forget something: 1) it is not how C# done it. 2) it is not how C# done it. 1) it is not how Java done it. 2) it is not how Java done it. ah, yes, sorry: i completely forgot that C++ was invented after c# and java. mea maxima culpa!
Re: how to make private class member private
On Tuesday, 13 March 2018 at 05:11:48 UTC, psychoticRabbit wrote: 1st - D has broken the concept of class encapsulation, simply for convenience at the module level. Not good in my opinion. No, it hasn't broken encapsulation. Encapsulation is at the module level. A class or struct and any supporting functions can be included in a single module and the private API is encapsulated from the outside world. 2nd - C++/C#/Java programmers will come to D, use the same syntax, but get very different semantics. Not good in my opinion. (i.e. I only realised private was not private, by accident). D is not C++, C#, or Java. C++ uses friend to get around the issue. Java has no solution. I don't know about C#. D has made many good design decisions. I do not see this as one of them. I think it's a great feature and I use it frequently. It's allows more flexibility in class design. Without it, we'd need another protection attribute to enable the concept of "private to the module". In Java, it's recommended to manipulate private member variables through their accessors even in methods of the same class. I've always found that extreme. If you need to make a breaking change to the member variable, you already have access to all of the method internals anyway. Yes, there's room for error if you forget to make a change, but with all the support in modern IDEs and editors for find/replace, it's a simple matter to handle it all at once. And in the standard edit-compile-run cycle, any breakage is discovered right away, not weeks down the road in the field. The same applies here. Encapsulation simply isn't broken by this feature.
Re: how to make private class member private
On Tuesday, 13 March 2018 at 05:52:55 UTC, ketmar wrote: psychoticRabbit wrote: There are two problems I see: 1) it is not how C++ done it. 2) it is not how C++ done it. and you're completely right: it is not how C++ done it. umm...didn't you forget something: 1) it is not how C# done it. 2) it is not how C# done it. 1) it is not how Java done it. 2) it is not how Java done it.
Re: how to make private class member private
psychoticRabbit wrote: There are two problems I see: 1) it is not how C++ done it. 2) it is not how C++ done it. and you're completely right: it is not how C++ done it.
Re: how to make private class member private
On Tuesday, 13 March 2018 at 05:35:30 UTC, Amorphorious wrote: There is another problem: 3rd: You are a brainwashed monkey who can't think for himself. No need for personal attacks. Let's keep it civil.
Re: how to make private class member private
On Tuesday, 13 March 2018 at 05:11:48 UTC, psychoticRabbit wrote: On Tuesday, 13 March 2018 at 02:24:38 UTC, Mike Parker wrote: On Tuesday, 13 March 2018 at 02:06:57 UTC, psychoticRabbit wrote: Mmm.. I don't think I like it. I feel you should be able to make a member of a class, private, regardless of where the class is located. This seems to break the concept of class encapsulation. No. I don't like it at all. If you have access to the module source, you have access to the source of types inside it. Making the module the lowest level of encapsulation makes sense from that perspective. There are two problems I see: 1st - D has broken the concept of class encapsulation, simply for convenience at the module level. Not good in my opinion. 2nd - C++/C#/Java programmers will come to D, use the same syntax, but get very different semantics. Not good in my opinion. (i.e. I only realised private was not private, by accident). D has made many good design decisions. I do not see this as one of them. There is another problem: 3rd: You are a brainwashed monkey who can't think for himself. See, You learned a little about C++/C#/Java and think the world must conform to what they say is correct and deny everything that contradicts it rather than first seeing if you are on the wrong side of the contradiction. The fact is, there is no reason a module should be restricted to see it's own classes private members. It's sorta like a family who runs around pretending that they can't see each others private parts. Sure, it sounds like a good thing... until someone accidentally drops the towel and the offended calls the cop on their brother and has him arrested for breaking the law. You should learn that your view of the world is very minute and stop trying to fit the world in to your box. It's called growing up. If you can't make a distinction between C++ encapsulation and D encapsulation you have far bigger problems than you think.
Re: how to make private class member private
On Tuesday, 13 March 2018 at 02:24:38 UTC, Mike Parker wrote: On Tuesday, 13 March 2018 at 02:06:57 UTC, psychoticRabbit wrote: Mmm.. I don't think I like it. I feel you should be able to make a member of a class, private, regardless of where the class is located. This seems to break the concept of class encapsulation. No. I don't like it at all. If you have access to the module source, you have access to the source of types inside it. Making the module the lowest level of encapsulation makes sense from that perspective. There are two problems I see: 1st - D has broken the concept of class encapsulation, simply for convenience at the module level. Not good in my opinion. 2nd - C++/C#/Java programmers will come to D, use the same syntax, but get very different semantics. Not good in my opinion. (i.e. I only realised private was not private, by accident). D has made many good design decisions. I do not see this as one of them.
Re: how to make private class member private
psychoticRabbit wrote: On Tuesday, 13 March 2018 at 01:39:13 UTC, Jonathan M Davis wrote: private is private to the module, not the class. There is no way in D to restrict the rest of the module from accessing the members of a class. This simplification makes it so that stuff like C++'s friend are unnecessary. If your class in a separate module from main, then main won't be able to access its private members. - Jonathan M Davis Mmm.. I don't think I like it. I feel you should be able to make a member of a class, private, regardless of where the class is located. This seems to break the concept of class encapsulation. No. I don't like it at all. just stop thinking in C/C++ "#include" terms. there, you have no other ways to restrict data access, so they were forced to make it broken, and then introduce "friends" just to workaround the fact that there are no modules in C++. instead, start thinking with modules in mind. module is THE unit of incapsulation. there is nothing wrong in isolating class or two in a module. then, to make imports manageable, either create a package of that, or just a dummy module that does `public import xxx;` for everything.
Re: how to make private class member private
On Tuesday, 13 March 2018 at 02:06:57 UTC, psychoticRabbit wrote: Mmm.. I don't think I like it. I feel you should be able to make a member of a class, private, regardless of where the class is located. This seems to break the concept of class encapsulation. No. I don't like it at all. If you have access to the module source, you have access to the source of types inside it. Making the module the lowest level of encapsulation makes sense from that perspective.
Re: how to make private class member private
On Tuesday, 13 March 2018 at 01:39:13 UTC, Jonathan M Davis wrote: private is private to the module, not the class. There is no way in D to restrict the rest of the module from accessing the members of a class. This simplification makes it so that stuff like C++'s friend are unnecessary. If your class in a separate module from main, then main won't be able to access its private members. - Jonathan M Davis Mmm.. I don't think I like it. I feel you should be able to make a member of a class, private, regardless of where the class is located. This seems to break the concept of class encapsulation. No. I don't like it at all.
Re: how to make private class member private
On Tuesday, March 13, 2018 01:12:15 psychoticRabbit via Digitalmars-d-learn
wrote:
> I cannot get my head around, why private is not private, in D.
>
> How do I make a private member, private?
>
> -
> module test;
>
> import std.stdio;
>
> void main()
> {
> myClass c = new myClass();
> c.myPrivateClassMember= "wtf";
> writeln(c.myPrivateClassMember);
> }
>
> class myClass
> {
> private string myPrivateClassMember; // private does not mean
> private anymore??
> }
>
> --
private is private to the module, not the class. There is no way in D to
restrict the rest of the module from accessing the members of a class. This
simplification makes it so that stuff like C++'s friend are unnecessary. If
your class in a separate module from main, then main won't be able to access
its private members.
- Jonathan M Davis
Re: how to make private class member private
Visibility modifiers in D are for the module, not class or struct. This is very useful to be able to access internal stuff outside of the abstraction and modify it sanely. While also keeping others at bay.
