Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
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.
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
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'.
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
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.
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
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?
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
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.
Re: Wed Oct 7 - Avoiding Code Smells by Walter Bright
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
Re: Wed Oct 7 - Avoiding Code Smells by Walter Bright
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.
Re: LDC 1.13.0-beta1
On Friday, 2 November 2018 at 21:04:13 UTC, kinke wrote: Glad to announce the first beta for LDC 1.13: * Based on D 2.083.0. * The Windows packages are now fully self-sufficient, i.e., a Visual Studio/C++ Build Tools installation isn't required anymore. Very cool! And very scary too, we'll have to verify the transcendantal precision and memcpy performance :)
Re: LDC 1.13.0-beta1
On Saturday, 3 November 2018 at 16:33:36 UTC, kinke wrote: I figured it'd be for a lot of Windows users. Why not explicitly express your gratitude with a little 'thank you' then? After all, that little bullet point in the release notes easily took some 40 hours of my spare time, and some appreciation can work wonders to keep motivation up. Thank you! Haven't yet had a chance to play around with it, but it's one of those little things that just makes everyone's life easier on Windows.
Re: LDC 1.13.0-beta1
On Monday, 5 November 2018 at 13:53:50 UTC, Guillaume Piolat wrote: On Friday, 2 November 2018 at 21:04:13 UTC, kinke wrote: Glad to announce the first beta for LDC 1.13: * Based on D 2.083.0. * The Windows packages are now fully self-sufficient, i.e., a Visual Studio/C++ Build Tools installation isn't required anymore. Very cool! And very scary too, we'll have to verify the transcendantal precision and memcpy performance :) Don't worry, we're not using anything from the MinGW runtime itself - just functions exported by the MS DLLs and some minimal startup/shutdown skeleton (`mainCRTStartup` entrypoint etc.). We (incl. DMD) are just using their .def files as basis for the generated import libraries.
Vibe.d on Raspberry Pi
As reported in https://forum.dlang.org/thread/rgmbwuwfihauvngqm...@forum.dlang.org I've written a brief tutorial for the Pi board. I'm pretty new to D and the community so any suggestion is really highly appreciated. Bye, Andrea
Re: LDC 1.13.0-beta1
On Saturday, 3 November 2018 at 16:33:36 UTC, kinke wrote: I figured it'd be for a lot of Windows users. Why not explicitly express your gratitude with a little 'thank you' then? After all, that little bullet point in the release notes easily took some 40 hours of my spare time, and some appreciation can work wonders to keep motivation up. Thanks for your work. I don't actually use Windows, but this is much bigger than just one user, as it makes D a viable option for data science. It allows the use of D by millions of R users who mostly know nothing about compiled languages. If you're looking for D's killer app, this is it. But that wasn't possible without a sane Windows installation experience - and having to tangle with VS made it unrealistic for 99.9%+ of all users. That restriction is now gone. Hopefully that gives you motivation to keep working.
Re: Wed Oct 7 - Avoiding Code Smells by Walter Bright
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
Re: Wed Oct 7 - Avoiding Code Smells by Walter Bright
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
Re: Vibe.d on Raspberry Pi
On Monday, 5 November 2018 at 16:06:38 UTC, Pander wrote: As reported in https://forum.dlang.org/thread/rgmbwuwfihauvngqm...@forum.dlang.org I've written a brief tutorial for the Pi board. I'm pretty new to D and the community so any suggestion is really highly appreciated. Bye, Andrea Nice! One suggestion: add the last step to the documentation that gets you a built and running server. It's a little thing, but it really helps people learning.
