Permalink
ReplyOn Monday, 6 June 2022 at 09:58:44 UTC, Ola Fosheim Grøstad wrote:
>Too many details to remember…
You don't need remember it at all, because only those who need it use it .Like C++'s friend, I don't use it at all .I don't care.
June 06, 2022 Re: Using closure in function scope to make "real" private class members | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Ola Fosheim Grøstad | ||||
June 06, 2022 Re: Using closure in function scope to make "real" private class members | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to zjh | On Monday, 6 June 2022 at 11:17:39 UTC, zjh wrote: >You don't need remember it at all, because only those who need it use it . Doesn't work, you need to read other people's code. Rarely used things should usually not be in the language. >Like Oh, but I remember most of C++'s language features! The C++ language itself is not so big. The complexity in C++ is elsewhere (what to do where if you want to avoid such and such problem, how to solve this and that issue, etc). | |||
June 06, 2022 Re: Using closure in function scope to make "real" private class members | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to forkit | On Monday, 6 June 2022 at 02:35:11 UTC, forkit wrote:
> On Monday, 6 June 2022 at 01:23:41 UTC, forkit wrote:
>>
>
> when your boss isn't really your friend:
>
> // ----
>
> module test;
> @safe :
>
> class Employee
> {
> }
>
> class Boss
> {
> }
>
Now that is real nonsense! Why should those two classes ever be within the same file?!?
Not everything is a friend - only what is in the same file! And unlike C++ you can have friends *only within the same file* and not also in whatever file belonging to some other developer.
Yes, unlike in Java you can have more than one class or other stuff in one file. But you should only put things in one file that really belong together (need access to implementation details). And that is really easy to keep under control. In my opinion much easier than in C++.
| |||
June 06, 2022 Re: Using closure in function scope to make "real" private class members | ||||
|---|---|---|---|---|
| ||||
Posted in reply to forkit | On Monday, 6 June 2022 at 04:34:23 UTC, forkit wrote:
> My argument is clear. It would be 'nice to have' 'an option' for there to be a genuine private component of a class. Not pseudo 'private', but genuine @private.
I would be ok with this, if it comes WITHOUT friends. Else it would destroy encapsulation like it does in C++.
And friends wouldn't be necessary, as we have the real D encapsulation as fallback, so why not. It's useless, but if you want it this urgently...
| |||
June 06, 2022 Re: Using closure in function scope to make "real" private class members | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Ola Fosheim Grøstad | On Monday, 6 June 2022 at 11:26:35 UTC, Ola Fosheim Grøstad wrote: >You need to learn more complicated things about | |||
June 06, 2022 Re: Using closure in function scope to make "real" private class members | ||||
|---|---|---|---|---|
| ||||
Posted in reply to zjh | On Monday, 6 June 2022 at 12:25:51 UTC, zjh wrote: >
(I am not blocking anything, how could I?) A large number of insignificant and random additions won't solve any big problems related to D projects. They will just make it more difficult to get to a good place, both in terms of language comprehension and in terms of compiler quality. Language additions should only come as a consequence of a targeted strategy that takes the whole language into consideration. The wishing-well approach does not work well for language design. How many pointless @keywords do you want on your screen? | |||
June 06, 2022 Re: Using closure in function scope to make "real" private class members | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to forkit | On Sunday, 5 June 2022 at 06:08:10 UTC, forkit wrote: > On Sunday, 5 June 2022 at 04:49:44 UTC, forkit wrote: >>[...] > > btw. > > here is a simple example, for demonstration purposes only, of the change that I'd like to see in D: > > [...] may I suggest you just use the proper tools for enforcing invariants? https://dlang.org/spec/class.html#invariants | |||
June 06, 2022 Re: Using closure in function scope to make "real" private class members | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Ola Fosheim Grøstad | On Monday, 6 June 2022 at 12:59:04 UTC, Ola Fosheim Grøstad wrote: >Language additions should only come as a consequence of a targeted strategy that takes the whole language into consideration. The wishing-well approach does not work well for language design. How many pointless @keywords do you want on your screen? @live is the latest addition. Just one more optional attribute and it'll fix all of D's problems. | |||
June 06, 2022 Re: Using closure in function scope to make "real" private class members | ||||
|---|---|---|---|---|
| ||||
Posted in reply to mee6 | On Monday, 6 June 2022 at 15:46:35 UTC, mee6 wrote: >@live is the latest addition. Just one more optional attribute and it'll fix all of D's problems. As long as | |||
June 07, 2022 Re: Using closure in function scope to make "real" private class members | ||||
|---|---|---|---|---|
| ||||
Posted in reply to zjh | On Monday, 6 June 2022 at 23:05:29 UTC, zjh wrote: >As long as Adding many variations of the same just makes code harder to read and mistakes easier to make. In most languages «private» has the same meaning. In D it has a slightly different meaning. That is ok, but somewhat annoying. If you now add «@private», which means the same as «private» in other languages, then experienced programmers will be confused and demand an explanation. In other words they will ask «what the hell went wrong in the design process, this is a mess». A well designed language has a small and expressive core. Adding special cases is not good, especially not if you have generic programming features. These are well established facts that all scholars agree upon. More mostly redundant stuff makes things worse, not better. If there are issues, go back to the drawing board and fix the core language. | |||
Copyright © 1999-2021 by the D Language Foundation