www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Wed Oct 7 - Avoiding Code Smells by Walter Bright

reply Walter Bright <newshound2 digitalmars.com> writes:
I'm giving a presentation at:

http://nwcpp.org/

See you there!
Oct 15
next sibling parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Monday, 15 October 2018 at 21:23:13 UTC, Walter Bright wrote:
 I'm giving a presentation at:

 http://nwcpp.org/

 See you there!
Where'd you get your time machine from? I want one!
Oct 15
next sibling parent bachmeier <no spam.net> writes:
On Monday, 15 October 2018 at 22:30:32 UTC, Nicholas Wilson wrote:
 On Monday, 15 October 2018 at 21:23:13 UTC, Walter Bright wrote:
 I'm giving a presentation at:

 http://nwcpp.org/

 See you there!
Where'd you get your time machine from? I want one!
std.timetravel was merged in DMD 2.082
Oct 15
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 10/15/2018 3:30 PM, Nicholas Wilson wrote:
 On Monday, 15 October 2018 at 21:23:13 UTC, Walter Bright wrote:
 I'm giving a presentation at:

 http://nwcpp.org/

 See you there!
Where'd you get your time machine from? I want one!
Gaaah! I mean Oct. 17.
Oct 15
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2018-10-15 23:23, Walter Bright wrote:
 I'm giving a presentation at:
 
 http://nwcpp.org/
 
 See you there!
Hmm, it doesn't mention your name until the speaker bio. -- /Jacob Carlborg
Oct 16
prev sibling next sibling parent reply Dukc <ajieskola gmail.com> writes:
On Monday, 15 October 2018 at 21:23:13 UTC, Walter Bright wrote:
 I'm giving a presentation at:
Is there a video about your talk "taking advantage of D in existing C codebases" at Code Europe? I recall that you were going to share it.
Oct 16
parent Walter Bright <newshound2 digitalmars.com> writes:
On 10/16/2018 1:50 AM, Dukc wrote:
 On Monday, 15 October 2018 at 21:23:13 UTC, Walter Bright wrote:
 I'm giving a presentation at:
Is there a video about your talk "taking advantage of D in existing C codebases" at Code Europe? I recall that you were going to share it.
They've still never posted any of the Code Europe 2018 videos. Sigh.
Oct 16
prev sibling next sibling parent reply Dennis <dkorpel gmail.com> writes:
On Monday, 15 October 2018 at 21:23:13 UTC, Walter Bright wrote:
 I'm giving a presentation at:

 http://nwcpp.org/

 See you there!
Will it be streamed live?
Oct 16
parent Walter Bright <newshound2 digitalmars.com> writes:
On 10/16/2018 3:26 AM, Dennis wrote:
 Will it be streamed live?
No. It will be recorded, and posted later.
Oct 16
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/15/2018 2:23 PM, Walter Bright wrote:
 I'm giving a presentation at:
 
 http://nwcpp.org/
 
 See you there!
Had a nice crowd there last night. Apparently lots of people were interested in this topic! Video: https://www.youtube.com/watch?v=lbp6vwdnE0k&feature=youtu.be Slides: http://nwcpp.org/talks/2018/code_smells.pdf
Oct 18
next sibling parent reply luckoverthere <luckoverthere gmail.cm> writes:
On Friday, 19 October 2018 at 03:53:12 UTC, Walter Bright wrote:
 On 10/15/2018 2:23 PM, Walter Bright wrote:
 I'm giving a presentation at:
 
 http://nwcpp.org/
 
 See you there!
Had a nice crowd there last night. Apparently lots of people were interested in this topic! Video: https://www.youtube.com/watch?v=lbp6vwdnE0k&feature=youtu.be Slides: http://nwcpp.org/talks/2018/code_smells.pdf
https://www.youtube.com/watch?v=lbp6vwdnE0k#t=42m01s Or it's a pain in the ass to try to get more than one pull request merged in due to lack of overseers. It's hard enough trying to get one pull request merged in, but trying to split one pull request into 4 and then try to micro manage it so that they are merged in order as the changes depend on each other (eg spelling error for a function). That becomes a nightmare when you don't have merging permission for a repo, especially for something like DMD where it's hard enough to get even a simple fix through the door.
Oct 20
parent reply David Gileadi <gileadisNOSPM gmail.com> writes:
luckoverthere <luckoverthere gmail.cm> wrote:
 On Friday, 19 October 2018 at 03:53:12 UTC, Walter Bright wrote:
 On 10/15/2018 2:23 PM, Walter Bright wrote:
 I'm giving a presentation at:
 
 http://nwcpp.org/
 
 See you there!
Had a nice crowd there last night. Apparently lots of people were interested in this topic! Video: https://www.youtube.com/watch?v=lbp6vwdnE0k&feature=youtu.be Slides: http://nwcpp.org/talks/2018/code_smells.pdf
https://www.youtube.com/watch?v=lbp6vwdnE0k#t=42m01s Or it's a pain in the ass to try to get more than one pull request merged in due to lack of overseers. It's hard enough trying to get one pull request merged in, but trying to split one pull request into 4 and then try to micro manage it so that they are merged in order as the changes depend on each other (eg spelling error for a function). That becomes a nightmare when you don't have merging permission for a repo, especially for something like DMD where it's hard enough to get even a simple fix through the door.
I unfortunately ran into this with my make-ddoc-support-markdown PR. The original PR was considered too big, and I was asked to split it into multiple PRs against a feature branch, which would then be merged into master. I was fine with this, and started the process. It was a bit slow, but seemed like it would work. Oh, what a fool I was! When my second PR to the feature branch was approved, it couldn’t be merged because it caused unrelated errors in the tests. My best theory is that the feature branch had drifted too far away from master, and since dmd, druntime and phobos have dependencies on each other it was somehow causing the test servers to fail. There’s a bit more to the story, but it boils down to the fact that since I don’t have permissions to update the feature branch, I’m basically dead in the water. So the work is all done and ready, but I have no path forward to get it in. And it’s a bit disheartening to be foiled by the machines :)
Oct 21
parent Walter Bright <newshound2 digitalmars.com> writes:
On 10/21/2018 1:29 PM, David Gileadi wrote:
 There’s a bit more to the story, but it boils down to the fact that since I
 don’t have permissions to update the feature branch, I’m basically dead in
 the water. So the work is all done and ready, but I have no path forward to
 get it in. And it’s a bit disheartening to be foiled by the machines :)
Just PR them against master.
Oct 21
prev sibling next sibling parent Basile B. <b2.temp gmx.com> writes:
On Friday, 19 October 2018 at 03:53:12 UTC, Walter Bright wrote:
 On 10/15/2018 2:23 PM, Walter Bright wrote:
 I'm giving a presentation at:
 
 http://nwcpp.org/
 
 See you there!
Had a nice crowd there last night. Apparently lots of people were interested in this topic! Video: https://www.youtube.com/watch?v=lbp6vwdnE0k&feature=youtu.be Slides: http://nwcpp.org/talks/2018/code_smells.pdf
https://www.reddit.com/r/programming/comments/9qbhw2/nwcpp_walter_bright_talks_about_the_code_smells/
Oct 22
prev sibling parent reply myCodeDontSmell <myCodeDontSmell gmail.com> writes:
On Friday, 19 October 2018 at 03:53:12 UTC, Walter Bright wrote:
 Had a nice crowd there last night. Apparently lots of people 
 were interested in this topic!

 Video: 
 https://www.youtube.com/watch?v=lbp6vwdnE0k&feature=youtu.be
Interesting talk. Thanks for the link. I did find it confusing however, that you discuss leaky abstractions, and putting your public interface at the beginning of your code (and all the other crap below it)... but then, in D, once your write your abstraction, say a class, with it's public interface, all the code below it can do whatever it likes to that class, making it a leaky abstraction. That's sure sound like code smell to me. i.e. A class (perhaps one of the most important abstractions in programming) within a module, is *always* a leaky abstraction (within the module), because of the way the code further down can just ignore the interface. In fact, there is no way at all to ensure code below the class uses that interface. So I can't help but see contradictions everywhere, in D.
Oct 30
next sibling parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Wednesday, 31 October 2018 at 05:00:12 UTC, myCodeDontSmell 
wrote:
 I did find it confusing however, that you discuss leaky 
 abstractions, and putting your public interface at the 
 beginning of your code (and all the other crap below it)... but 
 then, in D, once your write your abstraction, say a class, with 
 it's public interface, all the code below it can do whatever it 
 likes to that class, making it a leaky abstraction.

 That's sure sound like code smell to me.

 i.e. A class (perhaps one of the most important abstractions in 
 programming) within a module, is *always* a leaky abstraction 
 (within the module), because of the way the code further down 
 can just ignore the interface. In fact, there is no way at all 
 to ensure code below the class uses that interface.

 So I can't help but see contradictions everywhere, in D.
That is by design, because in D the unit of abstraction is the module, not the class. Running into such problems is a sign that your module is too large, and should become a package.
Oct 30
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Wednesday, 31 October 2018 at 05:42:26 UTC, Nicholas Wilson 
wrote:
 Running into such problems is a sign that your module is too 
 large, and should become a package.
I seen modules with more then thousand lines of code in the Phobos library. What exactly consist a module of being "too large"? If having two classes in a module with around 200-300 lines of code "too large"?
Oct 31
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 01/11/2018 2:16 AM, 12345swordy wrote:
 On Wednesday, 31 October 2018 at 05:42:26 UTC, Nicholas Wilson wrote:
 Running into such problems is a sign that your module is too large, 
 and should become a package.
I seen modules with more then thousand lines of code in the Phobos library. What exactly consist a module of being "too large"? If having two classes in a module with around 200-300 lines of code "too large"?
We have been splitting Phobos modules up: std.algorithm and most recently std.datetime They were MASSIVE as in 30k+ LOC massive.
Oct 31
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Wednesday, 31 October 2018 at 13:22:28 UTC, rikki cattermole 
wrote:
 On 01/11/2018 2:16 AM, 12345swordy wrote:
 On Wednesday, 31 October 2018 at 05:42:26 UTC, Nicholas Wilson 
 wrote:
 Running into such problems is a sign that your module is too 
 large, and should become a package.
I seen modules with more then thousand lines of code in the Phobos library. What exactly consist a module of being "too large"? If having two classes in a module with around 200-300 lines of code "too large"?
We have been splitting Phobos modules up: std.algorithm and most recently std.datetime They were MASSIVE as in 30k+ LOC massive.
That's nice. Again what consist of a module of being "too large"? That seems to me that more of a art then a science.
Oct 31
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 01/11/2018 2:25 AM, 12345swordy wrote:
 On Wednesday, 31 October 2018 at 13:22:28 UTC, rikki cattermole wrote:
 On 01/11/2018 2:16 AM, 12345swordy wrote:
 On Wednesday, 31 October 2018 at 05:42:26 UTC, Nicholas Wilson wrote:
 Running into such problems is a sign that your module is too large, 
 and should become a package.
I seen modules with more then thousand lines of code in the Phobos library. What exactly consist a module of being "too large"? If having two classes in a module with around 200-300 lines of code "too large"?
We have been splitting Phobos modules up: std.algorithm and most recently std.datetime They were MASSIVE as in 30k+ LOC massive.
That's nice. Again what consist of a module of being "too large"? That seems to me that more of a art then a science.
Because it is. My rules (which tend to be a little stricter than most peoples) are: Soft split 1k LOC, hard split 3k LOC without a very good reason not to. But at the end of the day, it just depends on the scope of the module. Is it getting to large? If so, split.
Oct 31
next sibling parent reply Stanislav Blinov <stanislav.blinov gmail.com> writes:
On Wednesday, 31 October 2018 at 13:28:54 UTC, rikki cattermole 
wrote:

 But at the end of the day, it just depends on the scope of the 
 module. Is it getting to large? If so, split.
Yup. LOC aren't a particulalry informative metric. Documentation, comments, unit tests, blanks, all contribute to it. Split by scope, by concept, by responsibility, by any implementation-relevant metric, not by LOC. As the joke goes, your word processor is doomed to fail once it also starts sending out emails...
Oct 31
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 01/11/2018 2:33 AM, Stanislav Blinov wrote:
 On Wednesday, 31 October 2018 at 13:28:54 UTC, rikki cattermole wrote:
 
 But at the end of the day, it just depends on the scope of the module. 
 Is it getting to large? If so, split.
Yup. LOC aren't a particulalry informative metric. Documentation, comments, unit tests, blanks, all contribute to it. Split by scope, by concept, by responsibility, by any implementation-relevant metric, not by LOC. As the joke goes, your word processor is doomed to fail once it also starts sending out emails...
Actually it is quite informative. As a code smell it does tell you pretty decently in my experience if your scope is too large or if you are in need of refactoring.
Oct 31
parent reply Stanislav Blinov <stanislav.blinov gmail.com> writes:
On Wednesday, 31 October 2018 at 13:37:07 UTC, rikki cattermole 
wrote:
 On 01/11/2018 2:33 AM, Stanislav Blinov wrote:
 On Wednesday, 31 October 2018 at 13:28:54 UTC, rikki 
 cattermole wrote:
 
 But at the end of the day, it just depends on the scope of 
 the module. Is it getting to large? If so, split.
Yup. LOC aren't a particulalry informative metric. Documentation, comments, unit tests, blanks, all contribute to it. Split by scope, by concept, by responsibility, by any implementation-relevant metric, not by LOC. As the joke goes, your word processor is doomed to fail once it also starts sending out emails...
Actually it is quite informative. As a code smell it does tell you pretty decently in my experience if your scope is too large or if you are in need of refactoring.
Well, yes, it can be a litmus test, I guess. I meant to say that it isn't per se a deciding factor.
Oct 31
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 01/11/2018 2:42 AM, Stanislav Blinov wrote:
 Well, yes, it can be a litmus test, I guess. I meant to say that it 
 isn't per se a deciding factor.
It is a deciding factor for me. Because it seems to be almost always correct. As I said, my rules are stricter than what most people have. My preferences may or may not be applicable for others tho.
Oct 31
prev sibling parent Atila Neves <atila.neves gmail.com> writes:
On Wednesday, 31 October 2018 at 13:33:52 UTC, Stanislav Blinov 
wrote:
 On Wednesday, 31 October 2018 at 13:28:54 UTC, rikki cattermole 
 wrote:

 But at the end of the day, it just depends on the scope of the 
 module. Is it getting to large? If so, split.
Yup. LOC aren't a particulalry informative metric. Documentation, comments, unit tests, blanks, all contribute to it. Split by scope, by concept, by responsibility, by any implementation-relevant metric, not by LOC. As the joke goes, your word processor is doomed to fail once it also starts sending out emails...
This is why the only measure is SLOC, not total lines, and one can measure SLOC easily with `dscanner --sloc` (for other languages I use sloccount). It probably counts unit tests though, which is unfortunate, but since my tests are always out-of-tree these days anyway...
Nov 06
prev sibling next sibling parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Wednesday, 31 October 2018 at 13:28:54 UTC, rikki cattermole 
wrote:
 On 01/11/2018 2:25 AM, 12345swordy wrote:
 On Wednesday, 31 October 2018 at 13:22:28 UTC, rikki 
 cattermole wrote:
 On 01/11/2018 2:16 AM, 12345swordy wrote:
 [...]
We have been splitting Phobos modules up: std.algorithm and most recently std.datetime They were MASSIVE as in 30k+ LOC massive.
That's nice. Again what consist of a module of being "too large"? That seems to me that more of a art then a science.
Because it is. My rules (which tend to be a little stricter than most peoples) are: Soft split 1k LOC, hard split 3k LOC without a very good reason not to. But at the end of the day, it just depends on the scope of the module. Is it getting to large? If so, split.
Ok, you agree that it is subjective. Why is having more then one class per file "too large"?
Oct 31
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 01/11/2018 2:35 AM, 12345swordy wrote:
 On Wednesday, 31 October 2018 at 13:28:54 UTC, rikki cattermole wrote:
 On 01/11/2018 2:25 AM, 12345swordy wrote:
 On Wednesday, 31 October 2018 at 13:22:28 UTC, rikki cattermole wrote:
 On 01/11/2018 2:16 AM, 12345swordy wrote:
 [...]
We have been splitting Phobos modules up: std.algorithm and most recently std.datetime They were MASSIVE as in 30k+ LOC massive.
That's nice. Again what consist of a module of being "too large"? That seems to me that more of a art then a science.
Because it is. My rules (which tend to be a little stricter than most peoples) are: Soft split 1k LOC, hard split 3k LOC without a very good reason not to. But at the end of the day, it just depends on the scope of the module. Is it getting to large? If so, split.
Ok, you agree that it is subjective. Why is having more then one class per file "too large"?
It doesn't. It is a group of related symbols. If it doesn't have function bodies (e.g. extern(C++) or COM) I would call that module to have too small of a scope.
Oct 31
parent 12345swordy <alexanderheistermann gmail.com> writes:
On Wednesday, 31 October 2018 at 13:39:25 UTC, rikki cattermole 
wrote:
 On 01/11/2018 2:35 AM, 12345swordy wrote:
 On Wednesday, 31 October 2018 at 13:28:54 UTC, rikki 
 cattermole wrote:
 On 01/11/2018 2:25 AM, 12345swordy wrote:
 [...]
Because it is. My rules (which tend to be a little stricter than most peoples) are: Soft split 1k LOC, hard split 3k LOC without a very good reason not to. But at the end of the day, it just depends on the scope of the module. Is it getting to large? If so, split.
Ok, you agree that it is subjective. Why is having more then one class per file "too large"?
It doesn't. It is a group of related symbols. If it doesn't have function bodies (e.g. extern(C++) or COM) I would call that module to have too small of a scope.
Why do anyone have to create a file for every class if they wanted them to be encapsulated then? Why can't we put them in the same file if they are relativity small?
Oct 31
prev sibling parent reply unprotected-entity <unprotected-entity gmail.com> writes:
On Wednesday, 31 October 2018 at 13:28:54 UTC, rikki cattermole 
wrote:
 On 01/11/2018 2:25 AM, 12345swordy wrote:
 On Wednesday, 31 October 2018 at 13:22:28 UTC, rikki 
 cattermole wrote:
 On 01/11/2018 2:16 AM, 12345swordy wrote:
 On Wednesday, 31 October 2018 at 05:42:26 UTC, Nicholas 
 Wilson wrote:
 Running into such problems is a sign that your module is 
 too large, and should become a package.
I seen modules with more then thousand lines of code in the Phobos library. What exactly consist a module of being "too large"? If having two classes in a module with around 200-300 lines of code "too large"?
We have been splitting Phobos modules up: std.algorithm and most recently std.datetime They were MASSIVE as in 30k+ LOC massive.
That's nice. Again what consist of a module of being "too large"? That seems to me that more of a art then a science.
Because it is. My rules (which tend to be a little stricter than most peoples) are: Soft split 1k LOC, hard split 3k LOC without a very good reason not to. But at the end of the day, it just depends on the scope of the module. Is it getting to large? If so, split.
I really do disagree. It's is not at all, about LOC. It is about clean architecture. D module's do not promote clean architecture. Why? Because private state is exposed to all code within a module. What will happen to clean architecture, when you make that available to programmers? Well.. we get phobos like architecture. Another thing to look for, is signs of code smell. I would include in this, unit tests calling private methods (which seems to be a popular thing for D programmers to do). Some will disagree that this is a code smell, but I have yet to see a good argument for why it is not. Forget LOC. Look for good architecture, decoupling, modularity, encapsulation, information hiding....etc..etc... again, sadly, these concepts are not directly promoted when writing modules in D, since the module exposes everything to everything else in the module - and programmers will surely make use of any convenient hack that avoids them having to think about good architecture ;-)
Oct 31
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Nov 01, 2018 at 02:45:19AM +0000, unprotected-entity via
Digitalmars-d-announce wrote:
[...]
 Another thing to look for, is signs of code smell. I would include in
 this, unit tests calling private methods (which seems to be a popular
 thing for D programmers to do). Some will disagree that this is a code
 smell, but I have yet to see a good argument for why it is not.
White-box testing. In principle, I agree with you that if your unittests are doing black-box testing, then they should definitely not be calling private methods. However, limiting yourself to black-box testing means your private functions can be arbitrarily complex and yet it's not thoroughly tested. Sometimes you really do want a unittest to ensure the private method is doing what you think it's doing, and this requires white-box testing. This is especially important to prevent regressions, even if it seems redundant at first. Only doing black-box testing means a later code change in the private method can subtly introduce a bug that's not caught by the unittest (because it cannot call a private method directly to verify this).
 Forget LOC. Look for good architecture, decoupling, modularity,
 encapsulation, information hiding....etc..etc... again, sadly, these
 concepts are not directly promoted when writing modules in D, since
 the module exposes everything to everything else in the module - and
 programmers will surely make use of any convenient hack that avoids
 them having to think about good architecture ;-)
[...] Actually, code within a module *should* be tightly coupled and cohesive -- that's the whole reason to put that code inside a single module in the first place. If two pieces of code inside a module are only weakly coupled or completely decoupled, that's a sign that they should not be in the same module at all. Or at the very least, they should belong in separate submodules that are isolated from each other. But besides all this, D's philosophy is about mechanism rather than policy. The goal is to give the programmer the tools to do what he needs to do, rather than a bunch of red tape to dictate what he cannot do. That's why we have trusted, system, and even asm. The programmer is responsible for making sane architectural decisions with the tools he is given, rather than being told what (not) to do within the confines of his cell. If you're looking for policy, maybe Java would suit you better. :-P T -- Nobody is perfect. I am Nobody. -- pepoluan, GKC forum
Oct 31
next sibling parent reply unprotected-entity <unprotected-entity gmail.com> writes:
On Thursday, 1 November 2018 at 03:10:22 UTC, H. S. Teoh wrote:
 Actually, code within a module *should* be tightly coupled and 
 cohesive -- that's the whole reason to put that code inside a 
 single module in the first place.  If two pieces of code inside 
 a module are only weakly coupled or completely decoupled, 
 that's a sign that they should not be in the same module at 
 all.  Or at the very least, they should belong in separate 
 submodules that are isolated from each other.
How does one determine, whether a 10,000 line module, is tightly coupled and cohesive? Only the author can make that statement - which they naturally will, even if it's not true. An outsider, seeking to verify that statement, has a hell of a job on their hands...(I for one, think code smell immediately). As soon as you see a class interface in a module, in D, you have to assume their is other code in the module, perhaps down around line 9,900, that is bypassing its interface, and doing who knows what to it.... Sure, the author might be happy, but an auditor/code reviewer, will likely have a different view, when a 10,000 line module is shoved in front of them, and they know, that 'anything goes', 'all bets are off', inside the D module....
 But besides all this, D's philosophy is about mechanism rather 
 than policy.  The goal is to give the programmer the tools to 
 do what he needs to do, rather than a bunch of red tape to 
 dictate what he cannot do.  That's why we have  trusted, 
  system, and even asm.  The programmer is responsible for 
 making sane architectural decisions with the tools he is given, 
 rather than being told what (not) to do within the confines of 
 his cell.  If you're looking for policy, maybe Java would suit 
 you better. :-P
I don't use a particular language. I'm more interested in design and architecture. In the age of 'lock-down-everything', increased modularity is becoming more important. A monolithic module approach, is already outdated, and risky, in terms of developing secure, maintainable software.... I think providing an additional tool, to those who seek to use D, such as 'strict private' (syntax can be argued about), would aid better design - it can't make it any worse, that's for sure). Although. I don't mean strict private like freepascal, but strict private, as in it inherits everything that private already does, but additionally, become private within the module too. Is that really such a bad idea? Are there no programmers out there in the D world that might think this could be a good, additional tool, to give programmers, so they can better architect their solution? The amount of push back in the D community on this idea, is really odd to me. I'm still trying to understand why that is. Are D programmers just hackers, insterested in getting their code to work, no matter what? Are their not enough Java/C# programmers coming to D - and bringing their design skills with them?
Nov 01
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Nov 01, 2018 at 10:37:59PM +0000, unprotected-entity via
Digitalmars-d-announce wrote:
 On Thursday, 1 November 2018 at 03:10:22 UTC, H. S. Teoh wrote:
 
 Actually, code within a module *should* be tightly coupled and
 cohesive -- that's the whole reason to put that code inside a single
 module in the first place.  If two pieces of code inside a module
 are only weakly coupled or completely decoupled, that's a sign that
 they should not be in the same module at all.  Or at the very least,
 they should belong in separate submodules that are isolated from
 each other.
How does one determine, whether a 10,000 line module, is tightly coupled and cohesive? Only the author can make that statement - which they naturally will, even if it's not true. An outsider, seeking to verify that statement, has a hell of a job on their hands...(I for one, think code smell immediately).
The code reviewer can reject a 10,000-line module off the bat as being too large. It's up to the project to enforce such conventions.
 As soon as you see a class interface in a module, in D, you have to
 assume their is other code in the module, perhaps down around line
 9,900, that is bypassing its interface, and doing who knows what to
 it....
 
 Sure, the author might be happy, but an auditor/code reviewer, will
 likely have a different view, when a 10,000 line module is shoved in
 front of them, and they know, that 'anything goes', 'all bets are
 off', inside the D module....
Yes, and this is when you, or the project manager, puts down the foot and say this is unacceptable, break this module up into smaller submodules or else it doesn't go into the master repository. Simple. [...]
 I don't use a particular language. I'm more interested in design and
 architecture.
 
 In the age of 'lock-down-everything', increased modularity is becoming
 more important. A monolithic module approach, is already outdated, and
 risky, in terms of developing secure, maintainable software....
I don't understand what D's approach to modules has to do with being monolithic. Why can't you just write smaller modules if private being module-wide bothers you so much? D has package.d that can make a set of smaller submodules appear as a larger module to outside code. Use it.
 I think providing an additional tool, to those who seek to use D, such
 as 'strict private' (syntax can be argued about), would aid better
 design - it can't make it any worse, that's for sure).
 
 Although. I don't mean strict private like freepascal, but strict
 private, as in it inherits everything that private already does, but
 additionally, become private within the module too.
 
 Is that really such a bad idea? Are there no programmers out there in
 the D world that might think this could be a good, additional tool, to
 give programmers, so they can better architect their solution?
It's not a bad idea. In fact, if I were in charge of designing D, I'd probably do the same. But D chose to do it differently -- and part of the rationale, if I understand it correctly, is to eliminate the need for `friend` declarations like in C++. But maybe Andrei or whoever it was that made this decision can step up and explain why it was designed this way. All we're saying is that it's not the end of the world if private is module-wide rather than aggregate-wide. You can still have your encapsulation by splitting up your code into smaller files, which, given what you said above, you want to be doing anyway since the idea of a 10,000-line source file is so abhorrent to you. The fundamental issue here is that there needs to be some kind of unit of encapsulation. Java and C# chose to make the class that unit; D chose the module. If the Java/C# unit of encapsulation is what you want, all you have to do is to make the module equivalent to the class, problem solved. It's not as though there is no encapsulation at all and you're left out in the wild west of C's global namespace, or that the workaround is too onerous to be practical.
 The amount of push back in the D community on this idea, is really odd
 to me. I'm still trying to understand why that is. Are D programmers
 just hackers, insterested in getting their code to work, no matter
 what? Are their not enough Java/C# programmers coming to D - and
 bringing their design skills with them?
It's not so much push back, as being worn out from every other newcomer clamoring for the same thing year after year without ever having tried to do it the D way. Not saying that you're doing that, but it just becomes a sort of knee-jerk reaction after X number of newcomers barge in repeating the same old complaints that has the same old answers that everyone is tired of repeating. Having said that, though, there are some here who *do* want something like what you describe... IIRC Manu has voiced this before, and there may be others. (I myself don't consider it a big enough issue to be worth agonizing over.) So far, there has yet to be a strong enough argument for per-aggregate private to convince Walter & Andrei. It's them you have to convince, not the rest of us. Even if we were to all agree with you, it doesn't mean squat if Walter and Andrei won't budge on the issue. And they are unlikely to budge as long as (1) there is a perfectly workable solution to the problem -- in this case, split up your code into submodules, and use package.d to group them into a logical parent module if you wish; and (2) the proposed language addition/change brings strong enough benefits to offset the technical debt of yet another complication added to the language. (Personally, I think they're a bit too conservative on changes that would ostensibly improve the language. But again, what I think means squat -- they are the decision-makers, not me.) T -- Which is worse: ignorance or apathy? Who knows? Who cares? -- Erich Schubert
Nov 01
parent unprotected-entity <unprotected-entity gmail.com> writes:
On Thursday, 1 November 2018 at 23:58:15 UTC, H. S. Teoh wrote:
 Having said that, though, there are some here who *do* want 
 something like what you describe... IIRC Manu has voiced this 
 before, and there may be others. (I myself don't consider it a 
 big enough issue to be worth agonizing over.)  So far, there 
 has yet to be a strong enough argument for per-aggregate 
 private to convince Walter & Andrei.  It's them you have to 
 convince, not the rest of us.  Even if we were to all agree 
 with you, it doesn't mean squat if Walter and Andrei won't 
 budge on the issue.
Again, I feel it's Walter and Andrei that should be doing the convincing.. they are always silent on this matter, which is a real shame,as I think their insights might actually be useful ;-) If it's simply not practical, from a language design, to consider this further, then I'd like to know that - I work at a higher leve of abstraction and have no idea about this. So not hearing from Walter or Andrei, is really unhelpful, as to whether it's an idea worth pursuing, or an idea that Walter and Andrei would never accept - which is it? Anyway, the real 'problem' (in my opinion), is not the idea. The idea is sound (or at least, it's not unsound), and it's represented in all major langauges, already. The real problem, is that whenever this idea pops up (as it has, and will continue to do so), far too many people on this forum attempt to divert the discussion from 'what is the usefulness of this new idea' to 'what's the difficulty of finding ways to avoid any change.' The discussion can never move forward under those circumstances. I would like the discussion to move forwards, and people start to think about how such a change could be adopted, how difficult it would be to implement, how will it play with other features in the langauge..etc.... It's a real shame we can't get beyond "No. We don't like your idea, and even if we did, we don't want to do it".
Nov 01
prev sibling next sibling parent reply Neia Neutuladh <neia ikeran.org> writes:
On Thu, 01 Nov 2018 22:37:59 +0000, unprotected-entity wrote:
 On Thursday, 1 November 2018 at 03:10:22 UTC, H. S. Teoh wrote:
 Actually, code within a module *should* be tightly coupled and cohesive
 -- that's the whole reason to put that code inside a single module in
 the first place.  If two pieces of code inside a module are only weakly
 coupled or completely decoupled, that's a sign that they should not be
 in the same module at all.  Or at the very least, they should belong in
 separate submodules that are isolated from each other.
How does one determine, whether a 10,000 line module, is tightly coupled and cohesive?
You can get a pretty accurate result by just saying "no". 10KLOC in one module is almost always a problem. Failing that, you can do a code review. Which will take a very long time. The solution to that is to submit less code at a time, review as you go, and keep modules smaller. For instance, Phobos keeps most modules below 3000 lines of code, including unittests. The largest module, std.datetime.systime, has about 6000 lines of code -- but if you exclude unittests and test-only code, it's more like 1000.
 Only the author can make that statement - which they naturally will,
 even if it's not true.
I think a lot of programmers are well aware of the failings of their code.
 As soon as you see a class interface in a module, in D, you have to
 assume their is other code in the module, perhaps down around line
 9,900, that is bypassing its interface, and doing who knows what to
 it....
And so you have a rule against casting from an interface to a concrete type, if that's a thing that worries you. It's something you can check rather easily in a reasonably sized code review.
 In the age of 'lock-down-everything', increased modularity is becoming
 more important. A monolithic module approach, is already outdated, and
 risky, in terms of developing secure, maintainable software....
That statement could be taken as being against an approach that recommends structuring a project as a monolithic module, or against an approach that treats modules as a monolith in terms of protection.
 I think providing an additional tool, to those who seek to use D,
 such as 'strict private' (syntax can be argued about), would aid better
 design - it can't make it any worse, that's for sure).
It would be more language complexity in order to make it easier to have large modules. But you already said that large modules are a problem.
 Is that really such a bad idea? Are there no programmers out there in
 the D world that might think this could be a good, additional tool, to
 give programmers, so they can better architect their solution?
The use case is when you don't want to break up a module and you don't trust yourself not to modify private members from the wrong parts of the module. That's not useless. It's also not obviously so useful as to merit inclusion. A lot of languages do without any notion of private. A lot, like the entire ALGOL family up to Oberon-2, Go, Rust, Lua, Haskell, and Node.js, use exported and unexported symbols instead, and that's per module. A fair number just don't have a notion of public and private symbols.
 The amount of push back in the D community on this idea, is really odd
 to me. I'm still trying to understand why that is. Are D programmers
 just hackers, insterested in getting their code to work, no matter what?
 Are their not enough Java/C# programmers coming to D - and bringing
 their design skills with them?
There are plenty of language designers that didn't think it obvious. Might be better to consider why instead of implying that no D programmers are familiar with or care about good design. I mean, if there are popular languages from the 1960s through the 2010s that do things the same way as D, that sounds like a pretty good indication that it's not an obviously bad idea. It's not rock-solid; actual evidence from the industry would be superior. But I think you would have presented that evidence already.
Nov 01
parent unprotected-entity <unprotected-entity gmail.com> writes:
On Friday, 2 November 2018 at 05:29:39 UTC, Neia Neutuladh wrote:
It's also not obviously so useful as to merit inclusion.
No. I don't say it merits inclusion. I do say it merits discussion, as to its merits. But from what I see, so far, is D, Go, Rust...they are seem to have a love affair with C like programming, but are to afraid to call it C. So they call it... modules. ... they're the wild west, where anything goes....(sorry, that thought had to come....just playing too much RDR2 at the moment...and as much fun as it looks, gee I'm glad we have the law now...well.. not always..)
Nov 02
prev sibling parent reply Laeeth Isharc <laeeth laeeth.com> writes:
On Thursday, 1 November 2018 at 22:37:59 UTC, unprotected-entity 
wrote:
 On Thursday, 1 November 2018 at 03:10:22 UTC, H. S. Teoh wrote:
 Actually, code within a module *should* be tightly coupled and 
 cohesive -- that's the whole reason to put that code inside a 
 single module in the first place.  If two pieces of code 
 inside a module are only weakly coupled or completely 
 decoupled, that's a sign that they should not be in the same 
 module at all.  Or at the very least, they should belong in 
 separate submodules that are isolated from each other.
How does one determine, whether a 10,000 line module, is tightly coupled and cohesive?
You take a look through it and make a judgement.
 Only the author can make that statement - which they naturally 
 will, even if it's not true.
?
 An outsider, seeking to verify that statement, has a hell of a 
 job on their hands...(I for one, think code smell immediately).
There is a basic question in life. Do you believe in discernment (if possible informed by data) or are you someone who makes decisions on the basis of evidence and believes that anything else is completely arbitrary and nothing more than a matter of opinion. My impression is that the values of the D community tend more in the direction of recognising the importance of discernment. If someone is somebody who believes more in 'evidence', policy and rules then it probably isn't going to be satisfying expecting one's values to be shared on a wide scale here. People also differ in their working memory and the degree to which they naturally think associatively. Chopping up everything into small pieces favours those who have a smaller working memory and who think more analytically but it's a disadvantage for those who have a large working memory and think associatively. For a private project that's something to be resolved between the relevant people, but I don't think it's reasonable to say that large files per se are wrong, just because they aren't your cup of tea personally. I think that lots of things seem clear in theory but the difference between theory and practice is often quite large. In practice Phobos is very readable. And on the other hand, I have seen an experienced and capable C# programmer struggle to understand an intranet site written in the approved way by an experienced person who was well-trained at Microsoft. I couldn't understand it either so I concatenated all the little itty bitty files, pulled out the data structures and then it was easy.
 I don't use a particular language. I'm more interested in 
 design and architecture.
Can one really speak of that kind of design in the abstract ? Language features shape your choices and lead to large shifts in the optimum. If you don't have design by introspection as a possibility you are going to pick something else.
 In the age of 'lock-down-everything', increased modularity is 
 becoming more important. A monolithic module approach, is 
 already outdated, and risky, in terms of developing secure, 
 maintainable software....
If you can't understand the program does that make you more or less secure? Security requires also to understand the behaviour of the system as a coherent whole. I think D programs are pretty easy from that perspective.
 Is that really such a bad idea? Are there no programmers out 
 there in the D world that might think this could be a good, 
 additional tool, to give programmers, so they can better 
 architect their solution?
Burden of proof is on you to write a DIP and make an argument for it. I am not sure you would find it easier to get a change into C++. Look at how difficult it is for Walter sometimes ; and he has just a little earned credibility. Same thing for Guido - he had such little fun with a recent PEP he decided to retire from BDFL of python.
 The amount of push back in the D community on this idea, is 
 really odd to me. I'm still trying to understand why that is.
Persuading people isn't easy even if it's a good idea. Look at the pushback from C++ over static if. They crippled it when they finally did relent. It's a bit entitled to think that if you can't persuade people without having written a DIP that it's them not you!
 Are D programmers just hackers, insterested in getting their 
 code to work, no matter what? Are their not enough Java/C# 
 programmers coming to D - and bringing their design skills with 
 them?
Would you mind explaining why you think that people from mass communities have design skills by virtue of having come from a mass community? Walter and Andrei are just a little bit known for their design capabilities so the bar is quite high. I think it's possible you might have things topsy turvy. Making D code work is rarely a problem. Every nation has its own strengths and weaknesses and the same is true of language communities. Having worked with D professionally since 2015 and with a decent size codebase in relation to what I have heard from others, my experience of working with D programmers is that I have never had to say please don't make this dirty hack. Whereas you know you could copy memory just this once, please don't bother making this bit fast, I really think we can just make a start on a prototype before doing a full design, do we really need to refactor this part of the code now - those things whilst not common are more frequent sources of disagreement with D programmers. So like I say I think you have it upside down. The D programmers I work with have a strong focus on design and doing things in the right way. Take a look at Atila Neves work on excel-d or dpp. It's a model of clean code. There are some outstanding Java and C# programmers but they are much sparser than in the D community. I spoke to the then CTO of the company where I am now involved. I was telling him about my project and he said ooh you want to spend a couple of weeks mapping out your class hierarchy. I said I don't have any classes. Well I did have two, but I took out one and John Colvin got rid of the other. The expression on his face was priceless. You can write D like Java or C# if you like. Depends what you are doing - you certainly don't need to, and many people who have been using D for a while often find writing code using structs much better for their goals and given their values. When one encounters a new idea that's unfamiliar sometimes it's easy to think that because it's unfamiliar it must be unsound. That can be a mistake. It might be better to suspend judgement for a while and keep an open mind.
Nov 02
next sibling parent reply unprotected-entity <unprotected-entity gmail.com> writes:
On Saturday, 3 November 2018 at 00:44:15 UTC, Laeeth Isharc wrote:
 When one encounters a new idea that's unfamiliar sometimes it's 
 easy to think that because it's unfamiliar it must be unsound.  
 That can be a mistake.  It might be better to suspend judgement 
 for a while and keep an open mind.
I believe that responses like this, are really just designed to further obfuscate the point I'm trying to make, so that it cannot progress any further. Now, speaking of keeping an open mind....let's get back to my point.. can we? (q1) Why is it, that people who use D, object *so much* to the idea of allowing (at the choice of the programmer) for a type to have it's own private state *within* a module (so that its private state is respected by other code also within that module)? Or you ask it another way: (q2)Why must a type within a module *always* have its private state exposed to other code within the module? (the key word here, being 'always'). Both questions seem very reasonable to ask, in my opinion, not matter what background you have. (q3) Should a language intentionally set out to prevent a programmer from making that choice? please stop obfuscating, and try to answer the questions.
Nov 02
next sibling parent reply Neia Neutuladh <neia ikeran.org> writes:
On Sat, 03 Nov 2018 04:50:52 +0000, unprotected-entity wrote:
 (q1) Why is it, that people who use D, object *so much* to the idea of
 allowing (at the choice of the programmer) for a type to have it's own
 private state *within* a module (so that its private state is respected
 by other code also within that module)?
We object because the people complaining can't point at a use case that seems reasonable. If you provided real-world examples, we'd consider them. We are further disinclined to engage with you as a collaborator because you're insulting us and ignoring a lot of our responses to you.
 Or you ask it another way:
 
 (q2)Why must a type within a module *always* have its private state
 exposed to other code within the module? (the key word here, being
 'always').
Because that is both simple and flexible. Swift forsakes simplicity in favor of high granularity, and it's exhausting just reading its protection modifier list.
 (q3) Should a language intentionally set out to prevent a programmer
 from making that choice?
You're mischaracterizing the situation to make your preferred feature look like the default. That's the opposite of how language design works. Nothing is there by default. You add things as necessary to get a language that's good enough.
Nov 02
next sibling parent reply FooledDonor <fooleddonor gmail.com> writes:
On Saturday, 3 November 2018 at 06:57:50 UTC, Neia Neutuladh 
wrote:
 On Sat, 03 Nov 2018 04:50:52 +0000, unprotected-entity wrote:
 (q1) Why is it, that people who use D, object *so much* to the 
 idea of
 allowing (at the choice of the programmer) for a type to have 
 it's own
 private state *within* a module (so that its private state is 
 respected
 by other code also within that module)?
We object because the people complaining can't point at a use case that seems reasonable. If you provided real-world examples, we'd consider them. We are further disinclined to engage with you as a collaborator because you're insulting us and ignoring a lot of our responses to you.
This reasoning is meaningless: one must not prove the obvious. During the writing of a complex module, it happened to me many times to desire what unprotected-entity asks. And if the validity of a person's reasoning is a function of his way of expressing them, well ... do not pose to software engineers at least
 Or you ask it another way:
 
 (q2)Why must a type within a module *always* have its private 
 state
 exposed to other code within the module? (the key word here, 
 being
 'always').
Because that is both simple and flexible. Swift forsakes simplicity in favor of high granularity, and it's exhausting just reading its protection modifier list.
 (q3) Should a language intentionally set out to prevent a 
 programmer
 from making that choice?
You're mischaracterizing the situation to make your preferred feature look like the default. That's the opposite of how language design works. Nothing is there by default. You add things as necessary to get a language that's good enough.
What he asks is reasonable and useful, and help in a myriad of cases. I can not even see a disadvantage in the introduction of a true private attribute. What you ask is reasonable and useful, and help in a myriad of cases. I can not even see a disadvantage in the introduction of a true private attribute. But already, it seems that nobody still really understands how to use the DIP1000 in the practicality of its code, "const-immutable" is a failure, five hundred pages of reasoning about "shared", entire sections of language abandoned halfway .... a poor man is asked to bring evidence that the water is wet .... geezzzz
Nov 03
parent reply Neia Neutuladh <neia ikeran.org> writes:
On Sat, 03 Nov 2018 11:24:06 +0000, FooledDonor wrote:
 And if the validity of a person's reasoning is a function of his way of
 expressing them, well ... do not pose to software engineers at least
If you want other people to do work for you, you need to convince them to do it. This is an open source project, so the appropriate way of doing this is with good reasoning and examples, not by insulting people. This is true even if the feature seems obviously good and necessary to one or two people, if those people don't have abnormally large influence over the project.
Nov 03
parent reply FooledDonor <fooleddonor gmail.com> writes:
On Saturday, 3 November 2018 at 16:21:36 UTC, Neia Neutuladh 
wrote:
 On Sat, 03 Nov 2018 11:24:06 +0000, FooledDonor wrote:
 And if the validity of a person's reasoning is a function of 
 his way of expressing them, well ... do not pose to software 
 engineers at least
If you want other people to do work for you, you need to convince them to do it. This is an open source project, so the appropriate way of doing this is with good reasoning and examples, not by insulting people.
The answer to your "if" is: NO, this is not the topic. The argument is: does the induction of a true "private" attribute add value to the language or not? It is possible to discuss, in these forums, or everything must be truncated with "if you want to do it, and best wishes to convince then W & A"
 This is true even if the feature seems obviously good and 
 necessary to one or two people, if those people don't have 
 abnormally large influence over the project.
Nothing is "necessary" to a language outside "turing completeness". Can we argue about the problems arising from the potential introduction of this feature?
Nov 04
parent reply Neia Neutuladh <neia ikeran.org> writes:
On Sun, 04 Nov 2018 11:36:39 +0000, FooledDonor wrote:
 Can we argue about the problems arising from the potential introduction
 of this feature?
There are many potential features that wouldn't cause problems in isolation. Should we add all of them? Obviously not; the result would be a horribly complex language that takes too much time to learn and is impossible to maintain. So instead, we need to aggressively filter out potential added features to ensure that what they add is sufficiently important to justify later maintenance costs and the effort of learning things. The justification for this feature rests on real-world examples of bugs that have been caused by its lack.
Nov 04
next sibling parent 12345swordy <alexanderheistermann gmail.com> writes:
On Sunday, 4 November 2018 at 15:40:03 UTC, Neia Neutuladh wrote:
 On Sun, 04 Nov 2018 11:36:39 +0000, FooledDonor wrote:
 Can we argue about the problems arising from the potential 
 introduction of this feature?
There are many potential features that wouldn't cause problems in isolation. Should we add all of them? Obviously not; the result would be a horribly complex language that takes too much time to learn and is impossible to maintain.
No one should/need learn the entire tool itself in order to get thing done. If you found yourself in such a situation, then you seriously need to rethink on what you should be doing. -Alex
Nov 04
prev sibling next sibling parent commonGripes <commonGripes outlook.com> writes:
On Sunday, 4 November 2018 at 15:40:03 UTC, Neia Neutuladh wrote:
 There are many potential features that wouldn't cause problems 
 in isolation. Should we add all of them? Obviously not; the 
 result would be a horribly complex language that takes too much 
 time to learn and is impossible to maintain.

 So instead, we need to aggressively filter out potential added 
 features to ensure that what they add is sufficiently important 
 to justify later maintenance costs and the effort of learning 
 things.

 The justification for this feature rests on real-world examples 
 of bugs that have been caused by its lack.
You keep turning this argument around, as though it is a request to change D. We should be able to have a discussion, about ways to further improve type safety inside a module, without being constantly taunted by your hyperbole. The discussion might even lead to ways to help programmers address the issues being raised, that don't require a change to D (and I don't mean 'just put your class/struct in it's own module'). Now, the fact is, that the D module is a conglomeration of different types. None of the types declared within a module has any independence from any other type, within the module. Fact. Some clearly think this is a good thing. Fine, you have it that way already. That will never change. But some think this requires an undue burden on the part of the programmer to be extra vigiliant around how they compose their types. Sure a few lines in module, you can easily do that. But as the number of line increase, so would the chances of you doing something you never intended to do. There is no way the programmer to provide a guarantee around the use of a type, from other code in the module, since the data and methods in any type are mutable from outside that type. Some think this shared mutability between types within a module, can lead to bugs and unsafe behaviour. Some think it might be nice, if the programmer had a means to provide better guarantees for the their declared types. Type safety is an important and critical component in software architecture. It's not something you should 'agressively filter out' from discussion. Whether the language could handle a change to address this, would be a further stage of the discussion. From what I hear, it may not be able to handle such a change, and the D module is doomed to be what it is, and programmers will bear the responsibilty for type safety within a module.
Nov 04
prev sibling parent reply nobodycares <nobodycares aboutD.com> writes:
On Sunday, 4 November 2018 at 15:40:03 UTC, Neia Neutuladh wrote:
 There are many potential features that wouldn't cause problems 
 in isolation. Should we add all of them? Obviously not; the 
 result would be a horribly complex language that takes too much 
 time to learn and is impossible to maintain.

 So instead, we need to aggressively filter out potential added 
 features to ensure that what they add is sufficiently important 
 to justify later maintenance costs and the effort of learning 
 things.

 The justification for this feature rests on real-world examples 
 of bugs that have been caused by its lack.
I think there are more than enough real-world examples, of where issues around 'type safety', or lack of, have caused a sufficient number of bugs, to warrant a discussion about ways to further improve type safety. D module's are not type safe, at least as far as the code within that module is concerned. To have to go to silly lengths just to get type safety in D. D is language the favors convenience 1st. type safety 2nd... or is it 3rd.. This lack of enforcable type safety *within* a module, leads to undisciplned code. Phobos is a 'real-world' example of it. D needs an 'Industrial Strength D' book, as well as an 'Effective D'. I assume the moderator(s) doesn't like me anymore, as my posts are no longer being published. Great way to run a discussion forum by the way.
Nov 04
next sibling parent 12345swordy <alexanderheistermann gmail.com> writes:
On Monday, 5 November 2018 at 01:23:44 UTC, nobodycares wrote:

 I assume the moderator(s) doesn't like me anymore, as my posts 
 are no longer being published. Great way to run a discussion 
 forum by the way.
It not just you, my post had disappear only to reappear on later dates. I can vouch for them by saying that this is a bug that you and I are experiencing. -Alex
Nov 04
prev sibling parent Neia Neutuladh <neia ikeran.org> writes:
On Mon, 05 Nov 2018 01:23:44 +0000, nobodycares wrote:
 I think there are more than enough real-world examples, of where issues
 around 'type safety', or lack of, have caused a sufficient number of
 bugs, to warrant a discussion about ways to further improve type safety.
You do realize we can all see that you're posting from the same IP address with three different usernames, don't you? How's the dual boot working out? Firefox 52 is kind of old; are you holding off on updating for addon compatibility? If you want to make a good sockpuppet, you'll need to invest some effort. Different browsers for each. Different IP addresses. Usernames that look like reasonable human names or forum handles. Posting about topics other than your personal cause. And if you had actual examples, you'd have shown them already.
Nov 04
prev sibling next sibling parent unprotected-entity <unprotected-entity gmail.com> writes:
On Saturday, 3 November 2018 at 06:57:50 UTC, Neia Neutuladh 
wrote:
 On Sat, 03 Nov 2018 04:50:52 +0000, unprotected-entity wrote:
 (q1) Why is it, that people who use D, object *so much* to the 
 idea of
 allowing (at the choice of the programmer) for a type to have 
 it's own
 private state *within* a module (so that its private state is 
 respected
 by other code also within that module)?
We object because the people complaining can't point at a use case that seems reasonable. If you provided real-world examples, we'd consider them. We are further disinclined to engage with you as a collaborator because you're insulting us and ignoring a lot of our responses to you.
 Or you ask it another way:
 
 (q2)Why must a type within a module *always* have its private 
 state
 exposed to other code within the module? (the key word here, 
 being
 'always').
Because that is both simple and flexible. Swift forsakes simplicity in favor of high granularity, and it's exhausting just reading its protection modifier list.
 (q3) Should a language intentionally set out to prevent a 
 programmer
 from making that choice?
You're mischaracterizing the situation to make your preferred feature look like the default. That's the opposite of how language design works. Nothing is there by default. You add things as necessary to get a language that's good enough.
la..de.da..de.dah... really just sounds like more obfuscatation to me... As I said, I don't think the 'please no, don't do it, it'll just make our syntax too complex' position can be taken seriously. And in any case, and how many time do I have to tell you this (turning your phrase to me, back on you), that this is NOT a request for change. This is just a discussion about what benefit it might provide, if the programmer had the choice to have declare private state for a type, and have the compiler enforce that design choice, by preventing other code within the module to have direct access to that types private state. Now..go and read that last paragraph again... no more obfuscation...please.
Nov 03
prev sibling parent reply unprotected-entity <unprotected-entity gmail.com> writes:
On Saturday, 3 November 2018 at 06:57:50 UTC, Neia Neutuladh 
wrote:
 We object because the people complaining can't point at a use 
 case that seems reasonable. If you provided real-world 
 examples, we'd consider them.
------ module test; struct S { private uint a; void setA(uint n) { // damn implicit conversions! I just hate them! if(n != 4294967286) this.a = n; else assert(0); } } void func(ref S s) { s.a = -10; // this might be on line 856 in your module. // there's a good chance, that when you get to write line 856, // that you've forgotten why you had written setA, on line 7. // i.e. to get around D's outrageous implicit conversions! // Even worse, in D, you may never know you mistyped here, // until things go wrong.. // maybe terribly wrong. // That's why I made 'a' private, and declared an interface for using it. } // compile with: -unittest -main unittest { S s = S(); func(s); // oh no...why did you do that! no error though. s.setA(-10); // gee.. if only I could declare 'a' to be: __private // then would I know something is wrong. } ----------
Nov 03
parent reply Stanislav Blinov <stanislav.blinov gmail.com> writes:
On Saturday, 3 November 2018 at 20:38:29 UTC, unprotected-entity 
wrote:

As has been pointed out several times before, this is a contrived 
example. Allow a simple transformation:

```
module test;

struct S
{
     private uint a;

     void setA(uint n)
     {
         // damn implicit conversions! I just hate them!
         if(n != 4294967286)
             this.a = n;
         else
             assert(0);
     }

     void func()
     {
         s.a = -10; // this might be on line 856 in your module.
                    // there's a good chance, that when you get to 
write line 856,
                    // that you've forgotten why you had written 
setA, on line 7.
                    // i.e. to get around D's outrageous implicit 
conversions!

     //  Even worse, in D, you may never know you mistyped here,
     //  until things go wrong..
     //  maybe terribly wrong.
     //  That's why I made 'a' private, and declared an interface 
for using it.
     }
}

// compile with: -unittest -main
unittest
{
     S s = S();
     s.func(); // oh no...why did you do that! no error though.

     s.setA(-10); // gee.. if only I could declare 'a' to be: 
__private then would I know something is wrong... [except it's 
useless in this case]
}
```

The only difference is that `func` became a member function. And 
now what? You can just as easily "forget" what's in your 
struct/class as in your whole module.
Nov 03
parent reply unprotected-entity <unprotected-entity gmail.com> writes:
On Saturday, 3 November 2018 at 21:28:22 UTC, Stanislav Blinov 
wrote:
 The only difference is that `func` became a member function. 
 And now what? You can just as easily "forget" what's in your 
 struct/class as in your whole module.
ok. Now, what are your options then (assuming you want an independent type)? (option 1) define one encapsulated type, per module. (option 2) have a means for type independence within a module - i.e. selective hiding. D only gives you one choice here, not two. I would say, that your response backs up my argument, that is, a second option might actually be worthwhile. perhaps, something like: __private (now __private is everything private already is, but additionally, its private outside the scope of the type declaring it, and now, you'd get a compile time guarantee of correctness - e.g. if you accidently tried to ignore that types independence. It's call 'type encapsulation' ;-)
Nov 04
next sibling parent Paul Backus <snarwin gmail.com> writes:
On Monday, 5 November 2018 at 05:55:02 UTC, unprotected-entity 
wrote:
 ok. Now, what are your options then (assuming you want an 
 independent type)?

 (option 1) define one encapsulated type, per module.
 (option 2) have a means for type independence within a module - 
 i.e. selective hiding.

 D only gives you one choice here, not two.
Is having two choices really better than having one choice? When you only have one choice, you don't have to make any decisions. When you have two choices, you are *forced* to make a decision, whether you want to or not. That can be a good thing, when the decision you're making is meaningful--for example, when you're deciding whether to use GC or manual memory management. But when the decision you're making is meaningless--for example, when you're deciding whether to indent with tabs or spaces--it's just a waste of time. It doesn't matter which you choose, but you're forced to make a decision anyway. (Or, even worse, your entire team is forced to waste time *agreeing* on a decision together.) When it comes to encapsulation, it makes no *functional* difference whether you achieve it by putting all your types into separate modules, or by using something like `__private`. The end result is the same either way. The only reason to prefer one over the other is personal taste--in other words, it's a matter of style, just like tabs vs. spaces. Personally, I don't think there's anything wrong with preferring `__private` over separate modules, just like I don't think there's anything wrong with preferring spaces over tabs. But I think being forced to make meaningless decisions is bad no matter what you prefer, and because of that, I don't think `__private` should be added to D.
Nov 05
prev sibling parent reply Stanislav Blinov <stanislav.blinov gmail.com> writes:
On Monday, 5 November 2018 at 05:55:02 UTC, unprotected-entity 
wrote:
 On Saturday, 3 November 2018 at 21:28:22 UTC, Stanislav Blinov 
 wrote:
 The only difference is that `func` became a member function. 
 And now what? You can just as easily "forget" what's in your 
 struct/class as in your whole module.
ok. Now, what are your options then (assuming you want an independent type)? (option 1) define one encapsulated type, per module. (option 2) have a means for type independence within a module - i.e. selective hiding.
Option 3 - don't access private state unless you intend to. That's literally how you write implementations, in pretty much any language that has access modifiers.
 D only gives you one choice here, not two.
Nope. You can have a type spanning several modules. That's what packages do, among other things.
 I would say, that your response backs up my argument, that is, 
 a second option might actually be worthwhile. perhaps, 
 something like: __private
No, it really doesn't. Your argument was that the programmer might accidentally forget, and I've shown quite clearly that no keyword is going to protect them from that. If you can forget in module scope, you can forget in class scope. There can be only one solution: don't forget. As in: stop inventing imaginary examples. People, in practice, don't "accidentally" modify the guts of their own types. That horse is quite dead, I'm afraid.
 (now __private is everything private already is, but 
 additionally, its private outside the scope of the type 
 declaring it, and now, you'd get a compile time guarantee of  
 correctness - e.g. if you accidently tried to ignore that types 
 independence.
No, you do not. You still have that same "problem" inside the type's definition.
 It's call 'type encapsulation' ;-)
If you're afraid of implicit conversions, define your own type that disallows them, problem solved. Has nothing to do with private. That is what's called 'type encapsulation'.
Nov 05
parent reply FooledDonor <fooleddonor gmail.com> writes:
On Monday, 5 November 2018 at 09:03:59 UTC, Stanislav Blinov 
wrote:
 On Monday, 5 November 2018 at 05:55:02 UTC, unprotected-entity 
 wrote:
 On Saturday, 3 November 2018 at 21:28:22 UTC, Stanislav Blinov 
 wrote:
 The only difference is that `func` became a member function. 
 And now what? You can just as easily "forget" what's in your 
 struct/class as in your whole module.
ok. Now, what are your options then (assuming you want an independent type)? (option 1) define one encapsulated type, per module. (option 2) have a means for type independence within a module - i.e. selective hiding.
Option 3 - don't access private state unless you intend to. That's literally how you write implementations, in pretty much any language that has access modifiers.
 D only gives you one choice here, not two.
Nope. You can have a type spanning several modules. That's what packages do, among other things.
 I would say, that your response backs up my argument, that is, 
 a second option might actually be worthwhile. perhaps, 
 something like: __private
No, it really doesn't. Your argument was that the programmer might accidentally forget, and I've shown quite clearly that no keyword is going to protect them from that. If you can forget in module scope, you can forget in class scope. There can be only one solution: don't forget. As in: stop inventing imaginary examples. People, in practice, don't "accidentally" modify the guts of their own types. That horse is quite dead, I'm afraid.
 (now __private is everything private already is, but 
 additionally, its private outside the scope of the type 
 declaring it, and now, you'd get a compile time guarantee of  
 correctness - e.g. if you accidently tried to ignore that 
 types independence.
No, you do not. You still have that same "problem" inside the type's definition.
 It's call 'type encapsulation' ;-)
If you're afraid of implicit conversions, define your own type that disallows them, problem solved. Has nothing to do with private. That is what's called 'type encapsulation'.
I'm glad you've worked only with excellent programmers, who in solitary write code in a module, knowing it to perfection, until the end of time. And I'm also glad you did not have to debug inherited code, maybe before the packages existed, tens of thousands of lines, and to make sure you do not start you had to cut and sew classes and private structures, just to check that the intentions of the programmer, who perhaps was not as good as you are. This your reiterate to every topic, thread, or question post on these forums with a "NO", is simply pathetic, as Manu has expounded a few weeks ago. Get off your pedestal, and drop into the real life of those who program in D with colleagues not as perfect as you are.
Nov 05
parent reply Mike Parker <aldacron gmail.com> writes:
On Monday, 5 November 2018 at 09:43:06 UTC, FooledDonor wrote:

 Get off your pedestal, and drop into the real life of those who 
 program in D with colleagues not as perfect as you are.
So where are these teams of imperfect D programmers who are plagued by accidental modifications of private class members? Sociomantic? Funkwerk? Weka?
Nov 05
next sibling parent FooledDonor <fooleddonor gmail.com> writes:
On Monday, 5 November 2018 at 11:07:11 UTC, Mike Parker wrote:
 On Monday, 5 November 2018 at 09:43:06 UTC, FooledDonor wrote:

 Get off your pedestal, and drop into the real life of those 
 who program in D with colleagues not as perfect as you are.
So where are these teams of imperfect D programmers who are plagued by accidental modifications of private class members? Sociomantic? Funkwerk? Weka?
You're right! How did I not think about it! I have to write on a public forum the name of the company and the name and surname of the colleagues I think are mediocre! Plagued, guess it! I deal with modules from well over 10k loc, I feel the lack of __private, during the study or debugging of certain monsters. You can believe it or not, it does not matter, it's your problem. But frankly this attitude where EVERYTHING must be demonstrated when talking to you veterans of the forum, has reached ridiculous peaks. As someone wrote before me, you should seriously rethink your open mind.
Nov 05
prev sibling parent reply TheFirefighter <TheFirefighter outlook.com> writes:
On Monday, 5 November 2018 at 11:07:11 UTC, Mike Parker wrote:
 So where are these teams of imperfect D programmers who are 
 plagued by accidental modifications of private class members? 
 Sociomantic? Funkwerk? Weka?
First, nobody needs to explain the problems that type errors create. Any decent programmer should already be well aware of such problems. Second, it's a matter of scale. How many D programmers are there? The probability that someone will do something silly, like below, will increase with scale. That's just how it is. Now. How many C++/Java/C# programmers are there? And, since the chance of error will increase with the number of users (and also the number of lines) how many of them would find that their compiler will happily compile the code below? and the is answer: zero no matter how many of them - it'll *always* be zero. unless they do it in D. ------ module test; class Firefighter { private void DoSomethingATraineeShouldNotDo() {} } class TraineeFirefighter : Firefighter {} unittest { TraineeFirefighter joe = new TraineeFirefighter(); joe.DoSomethingATraineeShouldNotDo(); } ----------
Nov 07
parent reply Dennis <dkorpel gmail.com> writes:
On Wednesday, 7 November 2018 at 11:00:49 UTC, TheFirefighter 
wrote:
 Now. How many C++/Java/C# programmers are there?
Even if a `super private` attribute or something is introduced, the semantics of private in D will not change. Your hypothetical C# programmer who switches to D assuming identical visiblity semantics to C# will still write that program that makes the plane crash. Luckily Java programmers write one class per file anyway. On Wednesday, 7 November 2018 at 11:00:49 UTC, TheFirefighter wrote:
 First, nobody needs to explain the problems that type errors 
 create.

 Any decent programmer should already be well aware of such 
 problems.
Look, you can keep making new accounts and restating that it's so obvious you don't need to convince anyone, and that D programmers are just stubborn. But it won't help advancing the discussion like you want. If you can't show that there are actual programmers writing appropriately sized modules containg bugs simply because of the lack of a class-private visibility level, then people don't want to engineer a solution to a seemingly non-existant problem, write and maintain the compiler code + specification for it, update existing tutorials, editors and tools, inform existing users about the change, and making the language more complex overall. Imagine if I made a proposal like this: "Hello, MrHaltingProblem here! We obviously need a noloops attribute. My co-workers are constantly writing buggy loops with wrong loop conditions so I NEED the extra protection. You're asking for a justification? Trust me, any decent programmer knows the importance of this. You are just too stubborn to see all the bugs that the lack of this attribute causes. Asking for real world examples? ``` class Plane { void doLandingProcedure() { // lots of code while (1) {} // OOPS! // lots of code } } ``` There! Now let's discuss the benefit of such a feature in D." This doesn't look like a compelling argument, so D programmers would probably suggest making more use of ranges instead.
Nov 07
next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 7 November 2018 at 13:15:03 UTC, Dennis wrote:
 [snip]

 "Hello, MrHaltingProblem here!

 We obviously need a  noloops attribute. My co-workers are 
 constantly writing buggy loops with wrong loop conditions so I 
 NEED the extra protection. You're asking for a justification? 
 Trust me, any decent programmer knows the importance of this. 
 You are just too stubborn to see all the bugs that the lack of 
 this attribute causes. Asking for real world examples?
 ```
 class Plane {
   void doLandingProcedure() {
     // lots of code
     while (1) {} // OOPS!
     // lots of code
   }
 }
 ```

 There! Now let's discuss the benefit of such a feature in D."

 This doesn't look like a compelling argument, so D programmers 
 would probably suggest making more use of ranges instead.
I get what you're saying here, but just to play devil's advocate, this feature could be added broadly to D without breaking any code. In particular, the disable attribute could be extended to 1) take some input, in this case a keyword (foreach, while, goto, etc) but potentially also symbols (I'm thinking mainly function names here), and 2) disable's behavior could be extended so that it works with like the protection attributes in terms of being able to use it as in disable(keyword) { } or disable(keyword):. For a start, something like nogc and nothrow are really just a special cases of disable(GC) and disable(Exception), or something. Also, the idea could be improved if there was some easy way to combine multiple attributes (there might be, but I don't know off the top of my head). Where I'm coming from is that these attributes aren't really based on any primitives. They are rather ad hoc. For instance, even this proposal would need additional work to enable safe and pure to be based on primitives. What if someone wanted to make disable(template) and have that enforced throughout their code? What if the decision not to include textual macros in D were instead set up as a default for disable(textual_macros)?
Nov 07
prev sibling parent reply TheFireFighter <TheFireFighter gmail.com> writes:
On Wednesday, 7 November 2018 at 13:15:03 UTC, Dennis wrote:
 If you can't show that there are actual programmers writing 
 appropriately sized modules containg bugs simply because of the 
 lack of a class-private visibility level, then people don't 
 want to engineer a solution to a seemingly non-existant 
 problem, write and maintain the compiler code + specification 
 for it, update existing tutorials, editors and tools, inform 
 existing users about the change, and making the language more 
 complex overall.
well you could say the same about pointers. but..what happens when a large number of programmers start using pointers? In the hands of few, it's not such a big issue. In the hands of the many, well.. we all know the result. Decades of bugs! Should we wait till the bugs start appearing? But my argument actually is less about bugs, or the potential for bugs (although that potential obviously exists). My argument is more about the 'untyped' nature of the D module. That is, a type (say a class) is 'naked' in a module, exposed for all (in that module) to see. It can be violated in any number of ways, by other code in the module. I mean that is just fact. It's not something I should need to continually point out. Some say that' fine. A class should be subjected to that humiliation. Other say, if you wan't to prevent that humiliation, then you can do it already - that is, you can clothe a class, in D, by 'walling it off' in it's *own* module. That immediately tells you something about the nature of the module. The module is essentially an untyped universe. It removes the clothes from the class, and allows it to be violated. On that basis, bugs (or the potential for them), becomes an immediate reality - and more so in the hands of the many, as opposed to the hands fo the few. Now, if you're one of those that object to the use of classes (and there are many in the D forums), then you would already be biased towards dismissing my argument, and don't mind at all if the class is subject to humiliation. I would prefer you refrain from the discussion, if such bias is going to be used to shutdown the argument. Because it just brings the tone of the discussion down to a level that nobody wants to participate in - likely it's goal in the first place. Lets be clear. My argument (not my DIP - as there is none) is, that it can only strengthen D, if D allowed the programmer the option (just the option) to ensure that a class wasn't subjected to such humiliation, when there is other code in the module besides that class. The major purpose of a class afterall (understood by most programmers), is to impose contraints on interactions with other objects (or other code), in order to enforce correctness and eliminate inconsistencies. It does this, by clothing itself, so that other types cannot operate directly on its naked representation. Yes, I know, you *can* clothe your class in D, but *only* if you wall it off in it's module. If you want 2 classes in your module, now you need to manage 2 classes across 2 different modules. That is an increase in complexity for the programmer. But you have no choice, because the very instance you put other code in that module, you remove that protective clothing. All I'm asking for, is the ability to have extra code in the module, without the module removing the clothes from my types. Is that really too much too ask? I do not understand the motivations of those that reject such an argument. (hopefully, the moderator will post this..you never know on these forums..peoples post are going missing, or show up in the wrong order, days later....what's going on?)
Nov 08
parent reply Dennis <dkorpel gmail.com> writes:
On Thursday, 8 November 2018 at 09:53:59 UTC, TheFireFighter 
wrote:
 well you could say the same about pointers. but..what happens 
 when a large number of programmers start using pointers?
I don't see the parallel between pointers and class-private.
 But my argument actually is less about bugs, or the potential 
 for bugs (although that potential obviously exists). My 
 argument is more about the 'untyped' nature of the D module.
That's a shame, I think the bug-argument is the stronger one.
 Now, if you're one of those that object to the use of classes 
 (and there are many in the D forums), then you would already be 
 biased towards dismissing my argument, and don't mind at all if 
 the class is subject to humiliation. I would prefer you refrain 
 from the discussion, if such bias is going to be used to 
 shutdown the argument.
My guess, based on my experience, is that bad coders will seek the shortest path to something that works. So if they need to quickly access a class-private member in the module they're working on, they'll remove the private attribute. But I don't know, I'm biased like everyone. I haven't worked in the same setting as you. That's why I'm really interested in hearing your perspective. I don't have a strong opinion on the importance of visibility attributes within a module, so I'm interested in hearing strong arguments from you. But so far, your arguments boil down to: - Avoiding justification - "Obviously" "I don't have to explain this" "Any decent programmer knows this" - Appeal to fear - "Just wait for all the problems that come in the future!" - Appeal to feeling - "Classes are naked, humiliated, their private parts are violated. That's so clearly wrong." I don't find such arguments strong. If they were, you could also justify adding the noloops attribute as I jokingly did in my previous post.
 Lets be clear. My argument (not my DIP - as there is none) is, 
 that it can only strengthen D, if D allowed the programmer the 
 option (just the option) to ensure that a class wasn't 
 subjected to such humiliation, when there is other code in the 
 module besides that class.
That sounds like "I just want there to be the option for aggregate value types... without using struct.". The question this raises is why the current solution is so problematic.
 I do not understand the motivations of those that reject such 
 an argument.
Do you agree that language additions add a lot of weight? If yes, then it's simply the fact that people don't think your suggestion bears that weight because it's already possible to do what you want in another way.
Nov 08
parent reply TheFireFighter <TheFireFighter gmail.com> writes:
On Thursday, 8 November 2018 at 13:18:30 UTC, Dennis wrote:
 That sounds like "I just want there to be the option for 
 aggregate value types... without using struct.". The question 
 this raises is why the current solution is so problematic.
I just want (for example) to be able to write a module, that contains a class, and also has non-member, non-friend functions. You simply cannot do that in a D module, as the class has no clothes - to extend the metaphor from my recent post. I refer you to Scott Meyers article about the benefits of having 'non-friend' non-member functions: How Non-Member Functions Improve Encapsulation (btw. people misread that title - it should be been "How Non-Friend, Non-Member..." http://www.drdobbs.com/cpp/how-non-member-functions-improve-encapsu/184401197?pgno=1
 Do you agree that language additions add a lot of weight? If 
 yes, then it's simply the fact that people don't think your 
 suggestion bears that weight because it's already possible to 
 do what you want in another way.
No it is not. You can keep saying there is, but it doesn't make it so. We don't seem to be on the same page here...do you misunderstand what I want? Fact: I cannot have a class in a module, and specify (so that the compiler can enforce it) that I want other code in the module to respect the specification of that class. It just cannot happen. Don't say it can. It can't. It's fact. As a result, one of my core guidelines are not applicable anymore, if I used D: " Don’t force together into a module things that will be used or maintained separately, and don’t separate things that will always be used and maintained together." Regarding the 'burden' to the D langauge, by providing the programmer with a tool to specify better encapsulation of code *within* the module: "I have become more and more convinced that the key to code reusability and scalability is encapsulation — having subsystems communicate through small, well-defined interfaces and letting them hide their own implementation details." - Walter Bright http://www.drdobbs.com/cpp/uniform-function-call-syntax/232700394?queryText=Scott%2BMeyers i.e. better encapsulation really is a good thing (although for many, it a lesson that needs to be learned).
Nov 08
next sibling parent Dennis <dkorpel gmail.com> writes:
On Thursday, 8 November 2018 at 23:50:18 UTC, TheFireFighter 
wrote:
 No it is not. You can keep saying there is, but it doesn't make 
 it so.
 ...
 We don't seem to be on the same page here...do you 
 misunderstand what I want?
Fair enough, the exact thing you want is not possible. I understand that. It's also a fact that you can't have a value-type class. But just because you can't have a value type *class* doesn't mean you can't have a value-type aggregate: there is struct. The higher goal of encapsulating classes is possible by writing one per module and using package.d, it's just not possible with the restriction that multiple classes must be in the same file.
 Regarding the 'burden' to the D langauge, by providing the 
 programmer with a tool to specify better encapsulation of code 
 *within* the module:

 [quote]

 i.e. better encapsulation really is a good thing (although for 
 many, it a lesson that needs to be learned).
Walter considers the module the lowest level of encapsulation, while you consider the class to be that. Neither is proven to be better so far. To change the D language in that regard, you have to convince people that class-private is superior/important enough to warrant the language change. Unfortunately, the arguments given so far have not done that yet, since they mostly appeal to feeling, fear and 'the obvious' as mentioned earlier.
Nov 08
prev sibling parent Sebastien Alaiwan <ace17 free.fr> writes:
On Thursday, 8 November 2018 at 23:50:18 UTC, TheFireFighter 
wrote:
 i.e. better encapsulation really is a good thing (although for  
 many, it a lesson that needs to be learned).
Public/private/protected are hacks anyway - and many object-oriented languages don't have it. They only provide extremely limited encapsulation ; the client still sees the non-public part, and can depend on it in unexpected ways: // my_module.d struct MyStruct { private: char[1024] data; } class MyClass { protected: abstract void f(); }; // main.d import my_module; import std.traits; import std.stdio; int main() { // depends on the list of private writefln("MyStruct.sizeof: %s", MyStruct.sizeof); members // depends on wether 'f' is declared abstract or not. writefln("isAbstractClass!MyClass: %s", isAbstractClass!MyClass); return 0; } If you want perfect encapsulation, use interfaces (as already said in this thread), or PIMPL.
Nov 09
prev sibling parent Atila Neves <atila.neves gmail.com> writes:
On Saturday, 3 November 2018 at 04:50:52 UTC, unprotected-entity 
wrote:
 On Saturday, 3 November 2018 at 00:44:15 UTC, Laeeth Isharc 
 wrote:
 [...]
I believe that responses like this, are really just designed to further obfuscate the point I'm trying to make, so that it cannot progress any further. Now, speaking of keeping an open mind....let's get back to my point.. can we? (q1) Why is it, that people who use D, object *so much* to the idea of allowing (at the choice of the programmer) for a type to have it's own private state *within* a module (so that its private state is respected by other code also within that module)?
Because it adds no value. Creating a new file is not expensive.
 (q2)Why must a type within a module *always* have its private 
 state exposed to other code within the module? (the key word 
 here, being 'always').
Because then `friend` isn't needed.
 (q3) Should a language intentionally set out to prevent a 
 programmer from making that choice?
Yes, given that it decreases the overall complexity of the language.
Nov 06
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/2/2018 5:44 PM, Laeeth Isharc wrote:
 When one encounters a new idea that's unfamiliar sometimes it's easy to think 
 that because it's unfamiliar it must be unsound. That can be a mistake.  It 
 might be better to suspend judgement for a while and keep an open mind.
So true. My ideas on how to write code have changed dramatically over the years, and continue to change.
Nov 03
next sibling parent reply unprotected-entity <unprotected-entity gmail.com> writes:
On Saturday, 3 November 2018 at 21:35:04 UTC, Walter Bright wrote:
 On 11/2/2018 5:44 PM, Laeeth Isharc wrote:
 When one encounters a new idea that's unfamiliar sometimes 
 it's easy to think that because it's unfamiliar it must be 
 unsound. That can be a mistake.  It might be better to suspend 
 judgement for a while and keep an open mind.
So true. My ideas on how to write code have changed dramatically over the years, and continue to change.
I hear the advantages of the way D does it. But nobody wants to hear about the disadvantages. Am I the only one who needs to keep an 'open mind'? What harm can come, from an optional tool, that enables enforceable encapsulation of a type, within a module (from code also in the module, but outside that type)? Can someone please answer that? And yet again, I remind people that this is not a request for change. This is a discussion about what benefit such a tool can bring.
Nov 04
parent Atila Neves <atila.neves gmail.com> writes:
On Monday, 5 November 2018 at 01:39:46 UTC, unprotected-entity 
wrote:
 On Saturday, 3 November 2018 at 21:35:04 UTC, Walter Bright 
 wrote:
 On 11/2/2018 5:44 PM, Laeeth Isharc wrote:
 When one encounters a new idea that's unfamiliar sometimes 
 it's easy to think that because it's unfamiliar it must be 
 unsound. That can be a mistake.  It might be better to 
 suspend judgement for a while and keep an open mind.
So true. My ideas on how to write code have changed dramatically over the years, and continue to change.
I hear the advantages of the way D does it. But nobody wants to hear about the disadvantages.
We heard you, we just disagree it's a disadvantage.
 What harm can come, from an optional tool, that enables 
 enforceable encapsulation of a type, within a module (from code 
 also in the module, but outside that type)?

 Can someone please answer that?
The harm is complexity. But hey, if you want to write such a tool go right ahead.
 And yet again, I remind people that this is not a request for 
 change. This is a discussion about what benefit such a tool can 
 bring.
In my opinion, no benefit at all.
Nov 06
prev sibling parent unprotected-entity <unprotected-entity gmail.com> writes:
On Saturday, 3 November 2018 at 21:35:04 UTC, Walter Bright wrote:
 On 11/2/2018 5:44 PM, Laeeth Isharc wrote:
 When one encounters a new idea that's unfamiliar sometimes 
 it's easy to think that because it's unfamiliar it must be 
 unsound. That can be a mistake.  It might be better to suspend 
 judgement for a while and keep an open mind.
So true. My ideas on how to write code have changed dramatically over the years, and continue to change.
what are your thoughts on implicit conversions, given your obvious experience? To me, implicit conversion are code smells, as they undermine the independence of types (and as you've probably gathered, I very much like type independence..a lot). Did you do it this way for C like compatability? Would you do it differently, if you could? uint x = -10; // what! int x; bool y = true; x = y; // what! etc..
Nov 04
prev sibling parent Atila Neves <atila.neves gmail.com> writes:
On Thursday, 1 November 2018 at 03:10:22 UTC, H. S. Teoh wrote:
 On Thu, Nov 01, 2018 at 02:45:19AM +0000, unprotected-entity 
 via Digitalmars-d-announce wrote: [...]
 Another thing to look for, is signs of code smell. I would 
 include in this, unit tests calling private methods (which 
 seems to be a popular thing for D programmers to do). Some 
 will disagree that this is a code smell, but I have yet to see 
 a good argument for why it is not.
White-box testing. In principle, I agree with you that if your unittests are doing black-box testing, then they should definitely not be calling private methods. However, limiting yourself to black-box testing means your private functions can be arbitrarily complex
If any of your functions are arbitrarily complex, you're doing it wrong (if alone) or your colleagues are (because it passed code review).
 and yet it's not thoroughly tested.
If it's not thoroughly tested via the public API, then either some of the private code is useless and should be deleted, or the public API tests aren't good enough.
 Sometimes you really do want a unittest to ensure the private 
 method is doing what you think it's doing, and this requires 
 white-box testing.
Only when writing the private method TDD-style. After it's written, I'd delete any and all tests for the private code and rely on the public API instead. Possibly useful when debugging though.
 This is especially important to prevent regressions, even if it 
 seems redundant at first.  Only doing black-box testing means a 
 later code change in the private method can subtly introduce a 
 bug that's not caught by the unittest (because it cannot call a 
 private method directly to verify this).
This makes no sense to me. If the public API tests didn't catch a regression, then the tests are bad. End of.
Nov 06
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/31/2018 6:25 AM, 12345swordy wrote:
 Again what consist of a module of being "too large"?
 That seems to me that more of a art then a science.
If you're looking for a rigid rule, you won't find one. But a good indicator is if it contains more than one abstraction that has nothing particular in common with each other.
Oct 31
parent 12345swordy <alexanderheistermann gmail.com> writes:
On Wednesday, 31 October 2018 at 20:23:21 UTC, Walter Bright 
wrote:
 On 10/31/2018 6:25 AM, 12345swordy wrote:
 Again what consist of a module of being "too large"?
 That seems to me that more of a art then a science.
If you're looking for a rigid rule, you won't find one. But a good indicator is if it contains more than one abstraction that has nothing particular in common with each other.
Sure thing, however I wonder why "protected package" doesn't exist for classes, seems to me a missing opportunity there.
Oct 31
prev sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 31 October 2018 at 13:16:45 UTC, 12345swordy wrote:
 I seen modules with more then thousand lines of code in the 
 Phobos library.
$ wc simpledisplay.d nanovega.d dom.d cgi.d 14152 54984 443111 simpledisplay.d 15289 63707 573986 nanovega.d 7159 24473 187572 dom.d 4132 16727 128299 cgi.d lol
Oct 31
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Wednesday, 31 October 2018 at 13:24:10 UTC, Adam D. Ruppe 
wrote:
 On Wednesday, 31 October 2018 at 13:16:45 UTC, 12345swordy 
 wrote:
 I seen modules with more then thousand lines of code in the 
 Phobos library.
$ wc simpledisplay.d nanovega.d dom.d cgi.d 14152 54984 443111 simpledisplay.d 15289 63707 573986 nanovega.d 7159 24473 187572 dom.d 4132 16727 128299 cgi.d
This is an counter argument how?
Oct 31
parent Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 31 October 2018 at 20:24:36 UTC, 12345swordy wrote:
 This is an counter argument how?
It isn't a counter argument (at least not to you). Just saying that I wrote a 14,000 line module, and maintain a contributed 15,000 line one. It works for me! lol
Oct 31
prev sibling parent reply Sebastien Alaiwan <ace17 free.fr> writes:
On Wednesday, 31 October 2018 at 05:00:12 UTC, myCodeDontSmell 
wrote:
 in D, once your write your abstraction, say a class, with it's 
 public interface, all the code below it can do whatever it 
 likes to that class, making it a leaky abstraction.
I think there might be some confusion between "leaky abstraction" and "insufficient encapsulation". Here's the Wikipedia definition of leaky abstractions: "In software development, a leaky abstraction is an abstraction that *requires* knowledge of an underlying complexity* to be able to know how to use it. This is an issue, as the whole point of an abstraction is to be able to abstract away these details from the user. " Why would imply that: as long as the user of your class isn't *required* to know about the underlying implementation specifics, this isn't a "leaky abstraction". My understanding is that: "Leaky abstractions" are about the interface design, and how one component is meant to be used. Those are unrelated to the programming language (e.g translating the code to another language doesn't make the leaky abstraction disappear). For example, a shared directory can be a leaky abstraction, if the network is unstable (because then, the client code, which only sees file descriptors, now has to deal with disappearing files). "Encapsulation" is about implementation hiding and access control ("public/private"), and requires programming language support (e.g most dynamic languages don't have it).
Oct 31
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 10/31/2018 3:48 AM, Sebastien Alaiwan wrote:
 I think there might be some confusion between "leaky abstraction" and 
 "insufficient encapsulation".
Thanks for the excellent description of the difference.
Oct 31
prev sibling parent reply unprotected-entity <unprotected-entity gmail.com> writes:
On Wednesday, 31 October 2018 at 10:48:24 UTC, Sebastien Alaiwan 
wrote:
 "Encapsulation" is about implementation hiding and access 
 control ("public/private"), and requires programming language 
 support (e.g most dynamic languages don't have it).
"Encapsulation is sometimes referred to as the first pillar or principle of object-oriented programming. According to the principle of encapsulation, a class or struct can specify how accessible each of its members is to code outside of the class or struct. Methods and variables that are not intended to be used from outside of the class .. can be hidden to limit the potential for coding errors or malicious exploits." https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/ D simply has *zero* support for encapsulation of classes or structs, within the module (only encapsulation from code that is outside the module). Any programmers interested in enforcing encapsulation in D (the first pillar of OOP), are *forced* (because the language doesn't provide the tool to do anything else) to use the one class, one struct, per file solution. Which seems really silly to me. D forces you into Java like programming - just to encapsulate a little class or struct. Speaking of 'structs', I don't see anyone in the D community, telling others to use 'one struct per module'.
Nov 01
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Nov 02, 2018 at 12:25:21AM +0000, unprotected-entity via
Digitalmars-d-announce wrote:
[...]
 "Encapsulation is sometimes referred to as the first pillar or
 principle of object-oriented programming. According to the principle
 of encapsulation, a class or struct can specify how accessible each of
 its members is to code outside of the class or struct. Methods and
 variables that are not intended to be used from outside of the class
 .. can be hidden to limit the potential for coding errors or malicious
 exploits."

 https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/
That is a narrow definition of encapsulation that is very OO-centric, and IMO, it sorta misses the larger point behind encapsulation, focusing instead on the mechanics of it, and that the specific implementation of it in the OO paradigm. The concept of encapsulation goes beyond OO and classes; it has to do with modularity and well-defined interfaces between modules (or units of encapsulation -- this is not necessary the same thing as a D module). It's fine to explain how OO's concept of classes and methods implement encapsulation, but to *define* encapsulation in terms of classes and methods is IMO missing the forest for the trees. If *that's* your basis for understanding encapsulation, it would it explain a lot of your reactions to this thread. But there is more to the world than the narrow realm of the OO paradigm, and in a multi-paradigm language like D, it doesn't seem to make sense to be handicapped by a definition of encapsulation that really only makes sense in the context of an OO language. What encapsulation is really about, is the ability to modularize your code into self-contained units which have well-defined interfaces, with private code and data that cannot be accessed outside of that unit. In OO languages, this unit would be the class. But in D, it's the module. That doesn't make D non-encapsulated; it just means we're using a different unit than an OO language. It's just a difference between pounds and dollars, not some fundamental discrepancy. You just have to convert one currency to another, that's all.
 D simply has *zero* support for encapsulation of classes or structs,
 within the module (only encapsulation from code that is outside the
 module).
 
 Any programmers interested in enforcing encapsulation in D (the first
 pillar of OOP), are *forced* (because the language doesn't provide the
 tool to do anything else) to use the one class, one struct, per file
 solution. Which seems really silly to me. D forces you into Java like
 programming - just to encapsulate a little class or struct.
 
 Speaking of 'structs', I don't see anyone in the D community, telling
 others to use 'one struct per module'.
Because we love UFCS, and structs just lend themselves very well to that sort of usage. And along that line, recent wisdom is that it's better to move things *out* of classes (and structs) if they don't need access to private members. (Sorry, I wanted to include a link for this, but I couldn't find the article -- the title eludes me and google isn't turning up anything useful.) Class and struct APIs should be as minimal as possible -- just enough to do what needs to be done and no more, and the rest of the syntactic sugar (that makes it more palatable to your users) belongs outside as optional convenience functions. T -- There is no gravity. The earth sucks.
Nov 01
parent reply ShadoLight <ettienne.gilbert gmail.com> writes:
On Friday, 2 November 2018 at 00:53:52 UTC, H. S. Teoh wrote:
 And along that line, recent wisdom is that it's better to move 
 things *out* of classes (and structs) if they don't need access 
 to private members. (Sorry, I wanted to include a link for 
 this, but I couldn't find the article -- the title eludes me 
 and google isn't turning up anything useful.)  Class and struct 
 APIs should be as minimal as possible -- just enough to do what 
 needs to be done and no more, and the rest of the syntactic 
 sugar (that makes it more palatable to your users) belongs 
 outside as optional convenience functions.
Maybe you are thinking of the "Prefer non-member non-friend functions to member functions" rule from Herb Sutter's "Effective C++" books?
Nov 02
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Nov 02, 2018 at 10:18:11AM +0000, ShadoLight via Digitalmars-d-announce
wrote:
 On Friday, 2 November 2018 at 00:53:52 UTC, H. S. Teoh wrote:
 
 And along that line, recent wisdom is that it's better to move
 things *out* of classes (and structs) if they don't need access to
 private members. (Sorry, I wanted to include a link for this, but I
 couldn't find the article -- the title eludes me and google isn't
 turning up anything useful.)  Class and struct APIs should be as
 minimal as possible -- just enough to do what needs to be done and
 no more, and the rest of the syntactic sugar (that makes it more
 palatable to your users) belongs outside as optional convenience
 functions.
 
Maybe you are thinking of the "Prefer non-member non-friend functions to member functions" rule from Herb Sutter's "Effective C++" books?
[...] Ah yes, that's the one. Thanks! T -- Democracy: The triumph of popularity over principle. -- C.Bond
Nov 02
prev sibling next sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 11/02/2018 03:18 AM, ShadoLight wrote:

 Maybe you are thinking of the "Prefer non-member non-friend functions to
 member functions" rule from Herb Sutter's "Effective C++" books?
Scott Meyers. Ali
Nov 02
parent ShadoLight <ettienne.gilbert gmail.com> writes:
On Saturday, 3 November 2018 at 03:58:16 UTC, Ali Çehreli wrote:
 On 11/02/2018 03:18 AM, ShadoLight wrote:

 Maybe you are thinking of the "Prefer non-member non-friend
functions to
 member functions" rule from Herb Sutter's "Effective C++"
books? Scott Meyers. Ali
<Facepalm!> Thanks for the correction.
Nov 04
prev sibling parent Atila Neves <atila.neves gmail.com> writes:
On Friday, 2 November 2018 at 10:18:11 UTC, ShadoLight wrote:
 On Friday, 2 November 2018 at 00:53:52 UTC, H. S. Teoh wrote:
 And along that line, recent wisdom is that it's better to move 
 things *out* of classes (and structs) if they don't need 
 access to private members. (Sorry, I wanted to include a link 
 for this, but I couldn't find the article -- the title eludes 
 me and google isn't turning up anything useful.)  Class and 
 struct APIs should be as minimal as possible -- just enough to 
 do what needs to be done and no more, and the rest of the 
 syntactic sugar (that makes it more palatable to your users) 
 belongs outside as optional convenience functions.
Maybe you are thinking of the "Prefer non-member non-friend functions to member functions" rule from Herb Sutter's "Effective C++" books?
C++ however doesn't have reflection. The problem with non-member functions is I can't reflect on a type and loop over its member functions if some of the functionality is somewhere else.
Nov 06
prev sibling parent reply Codifies <a b.com> writes:
I subscribed to this forum in the hope I'd get irregular updates 
on useful and interesting things related to the D language.

This thread as far as I see it had degenerated into a somewhat 
childish and unproductive waste of time, I wouldn't object to a 
moderator locking this thread
Nov 05
next sibling parent drug <drug2004 bk.ru> writes:
On 05.11.2018 15:19, Codifies wrote:
 I subscribed to this forum in the hope I'd get irregular updates on 
 useful and interesting things related to the D language.
 
 This thread as far as I see it had degenerated into a somewhat childish 
 and unproductive waste of time, I wouldn't object to a moderator locking 
 this thread
Unfortunately you're totally right and this is consequence of D popularity increasing. Before threads were much more professional and productive. Andrey decreased his participating in the forum due to this reason.
Nov 05
prev sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 11/5/18 7:19 AM, Codifies wrote:
 I subscribed to this forum in the hope I'd get irregular updates on 
 useful and interesting things related to the D language.
 
 This thread as far as I see it had degenerated into a somewhat childish 
 and unproductive waste of time, I wouldn't object to a moderator locking 
 this thread
There is a troll here posting as multiple different aliases, who has tried this before, and continually comes back to harp on the same issue. It's why I haven't participated, he doesn't need to have more encouragement. Just give it time, he will give up and go back to being a lurker. It would be good if people just stop responding here. -Steve
Nov 05
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Nov 05, 2018 at 11:50:34AM -0500, Steven Schveighoffer via
Digitalmars-d-announce wrote:
 On 11/5/18 7:19 AM, Codifies wrote:
 I subscribed to this forum in the hope I'd get irregular updates on
 useful and interesting things related to the D language.
 
 This thread as far as I see it had degenerated into a somewhat
 childish and unproductive waste of time, I wouldn't object to a
 moderator locking this thread
There is a troll here posting as multiple different aliases, who has tried this before, and continually comes back to harp on the same issue. It's why I haven't participated, he doesn't need to have more encouragement. Just give it time, he will give up and go back to being a lurker. It would be good if people just stop responding here.
[...] Yeah, after a while I realized that he was not sincere about contributing constructively, and I just stopped responding. It's simply not worth the time and effort, and it only generates more noise anyway. It's standard online forum advice, guys: don't feed the troll. T -- The most powerful one-line C program: #include "/dev/tty" -- IOCCC
Nov 05
prev sibling parent unprotected-entity <unprotected-entity gmail.com> writes:
On Monday, 5 November 2018 at 16:50:34 UTC, Steven Schveighoffer 
wrote:
 There is a troll here posting as multiple different aliases, 
 who has tried this before, and continually comes back to harp 
 on the same issue. It's why I haven't participated, he doesn't 
 need to have more encouragement.

 Just give it time, he will give up and go back to being a 
 lurker. It would be good if people just stop responding here.

 -Steve
it sounds like you're referring to me?? but which of my posts in this thread are trolling? can you show me? all most posts were resepectful, and were on the topic that I sought to discuss. false accusations are NOT appreciated! The problem is, I wanted to discuss the problems that are associated with public being the default, and private being 'kinda private'. It is the D TROLLS that ALWAYS come out to ruin that discussion by accusing me of wanting to change D. That is self-evident - just go back and read this thread - if the truth matters to you. I sought to have a decent, respectful discussion. Instead, I get D TROLLS coming out, who clearly hate OOP (and perhaps hate OO programmers), and start accusing me of wanting to turn D into an OOP language. No, I just wanted to discuss the potential benefits of increasing encapsulation within a module - that's it. Why is that so hard to do in the D forum? I don't get it. Again, get your facts straight next time. (of course, you'll likely never see this post, as there is a clear bias going on with the forum moderators too!)
Nov 06