On Thursday, 23 June 2022 at 06:33:37 UTC, forkit wrote:
>I'm using dkorpel's 'private-this' branch of dmd, and it's doing just what I want.
Good for you! :)
June 23, 2022 Re: `restricted` member variables | ||||
---|---|---|---|---|
| ||||
Posted in reply to forkit | On Thursday, 23 June 2022 at 05:22:26 UTC, forkit wrote:
> On Thursday, 23 June 2022 at 05:09:17 UTC, forkit wrote:
>>
>
> gather around kids...
>
> This is how encapsulation is achieved.
>
> Each object is in charge of its own state.
>
> Each object keeps that state private.
>
> Other objects don’t have direct access to this state.
>
> Instead, they can only call a list of public functions — called methods.
>
> Now if your using the D programming langauge, this isn't the entire story. The rest of that story is in that big, black, scary book on the top shelf. In that book, you can make a cat bark, if you want. But we won't go there. It's too scary!
>
> "How to explain object-oriented programming concepts to a 6-year-old"
>
> https://www.freecodecamp.org/news/object-oriented-programming-concepts-21bb035f7260/
Well, you what they say, if first you don't succeed (with copy/pasted appeals to authority), then try, try again (this time, with extra condescension).
|
June 23, 2022 Re: `restricted` member variables | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jordan Wilson | On Thursday, 23 June 2022 at 06:55:30 UTC, Jordan Wilson wrote:
>
> ..
> Well, you what they say, if first you don't succeed (with copy/pasted appeals to authority), then try, try again (this time, with extra condescension).
really. that's what they say?
you mean, i did it right?
|
June 23, 2022 Re: `restricted` member variables | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jordan Wilson | On Thursday, 23 June 2022 at 06:55:30 UTC, Jordan Wilson wrote:
>
> ..
> Well, you what they say, if first you don't succeed (with copy/pasted appeals to authority), then try, try again (this time, with extra condescension).
btw. I noticed you said NOTHING, ABSOLUTELY NOTHING, when the condescension was being directed towards me.
I guess we know which side of the debate your on.
|
June 23, 2022 Re: `restricted` member variables | ||||
---|---|---|---|---|
| ||||
Posted in reply to forkit | On Thursday, 23 June 2022 at 06:33:37 UTC, forkit wrote: >I'm using dkorpel's 'private-this' branch of dmd, and it's doing just what I want. Good for you! :) |
June 23, 2022 Re: `restricted` member variables | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ola Fosheim Grøstad | On Thursday, 23 June 2022 at 05:41:19 UTC, Ola Fosheim Grøstad wrote: >Stronger typing is desirable in complex performance oriented system level programming. This is the biggest weakness of C. Modules are clearly weaker than class/struct level protection. Weaker typing is not better in this context. It is exceedingly uncommon for a property to be all good or all bad. If it was unambiguously true that tighter control is always better, all languages would just do very tight control. But in practice, they don't. Usually, while you increase things on one axis, you also diminish them on another. |
June 23, 2022 Re: `restricted` member variables | ||||
---|---|---|---|---|
| ||||
Posted in reply to forkit | On Thursday, 23 June 2022 at 05:51:47 UTC, forkit wrote:
> Even Javascript has realised this recently. It's more powerful than D now, as far as strong typing goes! I never thought I'd say that...yeepers!
>
Have you considered that this move is 1/ not that recent (it 10+ years old now) and 2/ some of the people you are arguing against have worked on building these systems?
|
June 23, 2022 Re: `restricted` member variables | ||||
---|---|---|---|---|
| ||||
Posted in reply to deadalnix | On Thursday, 23 June 2022 at 09:30:49 UTC, deadalnix wrote: >Usually, while you increase things on one axis, you also diminish them on another. I don't see how providing more expressive constraints diminish anything on a semantic level if sound. There is an implementation/design/educational cost, but history suggests that languages over time add more expressive constraints: C++ concepts/consteval, Python typing module, TypeScript, JavaScript classes/private. |
June 23, 2022 Re: `restricted` member variables | ||||
---|---|---|---|---|
| ||||
Posted in reply to forkit | On Thursday, 23 June 2022 at 03:55:00 UTC, forkit wrote: > On Thursday, 23 June 2022 at 01:27:23 UTC, Mike Parker wrote: > Well, the 'invariant' statement in D, is interesting, but no replacement for strong typing. If you accept that one module should only contain one class and it's friends, then it is strong typed. Hey, even the OS support its encapsulation: you can make the file read only. What better encapsulation do you want? > I cannot put "wtf" into an int. Yes. Because from user perspective it is encapsulated. But if you own the module where int is implemented, of course you can add "wtf" there! If you want your class to be encapsulated the same way, put it in its own module and make it read only. You can be sure nobody can add "wtf" to your class, just like with int. > I no longer have to put that type in its own module But this is just coding style. And here you see the cost of private(this). As of now, everybody reading a D source file can be sure everything in a module belongs together. Because a special coding style is enforced on the developers by the language. With private(this) that assumption no longer holds. You can conflate everything in one file. Just because now you have that option. Can you see that it has some negative impact? It's benefit has to outweight that impact, or it is not worth adding it. And many people in this forum think it doesn't. That is why they insist on you presenting evidence of the benefit. Coding style guides are good. It makes a language much more readable if everybody is enforced to do one thing always the same way. Of course they reduce your freedom. If you were a poet, that would be really bad. But as a programmer do you need that freedom? Isn't it sufficient, that there *is* one way to do something? |
June 23, 2022 Re: `restricted` member variables | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ola Fosheim Grøstad | On Thursday, 23 June 2022 at 09:42:59 UTC, Ola Fosheim Grøstad wrote: >On Thursday, 23 June 2022 at 09:30:49 UTC, deadalnix wrote: >Usually, while you increase things on one axis, you also diminish them on another. I don't see how providing more expressive constraints diminish anything on a semantic level if sound. No, but this whole discussion is only about coding style (putting each class in its own module or not). And from style guide perspective having more options is always bad. It reduces the readability. |
June 23, 2022 Re: `restricted` member variables | ||||
---|---|---|---|---|
| ||||
Posted in reply to forkit | On Thursday, 23 June 2022 at 07:04:55 UTC, forkit wrote: > On Thursday, 23 June 2022 at 06:55:30 UTC, Jordan Wilson wrote: >> >> .. >> Well, you what they say, if first you don't succeed (with copy/pasted appeals to authority), then try, try again (this time, with extra condescension). > > btw. I noticed you said NOTHING, ABSOLUTELY NOTHING, when the condescension was being directed towards me. The last 60 messages to the General forums, almost 50% are from yourself. If I've picked up on certain undesirable tones from your messages, it's simply due to the quantity presented. > I guess we know which side of the debate your on. No need to guess. If private(scope) was introduced to the D language, I'd go "cool". If you asked if I supported such a DIP, I'd go "sure". If others disagreed with me, what I wouldn't do imply that those that disagree: - are kids - are not 'actually' interested in learning about it (i.e. willfully ignorant) - make grand sweeping statements like "D can finally be taken seriously [when this feature is implemented]" (the list could go on) Look, I commend you wanting D to be better; I cannot commend how you have been trying to achieve this. Jordan |