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: Note how fast Martin produced this beta release after the DMD 2.083 release. Thanks to all contributors! The main contributor by far is you Martin, thank _you_! -Johan
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
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.
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
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.
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
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.
}
--
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Saturday, 3 November 2018 at 06:57:50 UTC, Neia Neutuladh wrote: On Sat, 03 Nov 2018 04:50:52 +, 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.
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. * Substantial debug info improvements for GDB. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.13.0-beta1 Thanks to all contributors! You ‘re quick! Great work.
Re: LDC 1.13.0-beta1
On 03.11.2018 19:33, 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. Not a Windows user at all but I'd like to thank you for your job! It's really great and I know how boring things like that are.
Re: LDC 1.13.0-beta1
On Saturday, 3 November 2018 at 00:42:46 UTC, bachmeier wrote: On Friday, 2 November 2018 at 21:04:13 UTC, kinke wrote: * The Windows packages are now fully self-sufficient, i.e., a Visual Studio/C++ Build Tools installation isn't required anymore. That's a very big deal for me. It will be realistic for R users on Windows to use packages that contain D code. 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.
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Sat, 03 Nov 2018 11:24:06 +, 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.
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Saturday, 3 November 2018 at 06:57:50 UTC, Neia Neutuladh wrote: On Sat, 03 Nov 2018 04:50:52 +, 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 gee
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Sat, 03 Nov 2018 04:50:52 +, 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.
