Adding a new design constraint to D (page 6)

class A { public: inline void f(); inline void g(); private: class X { int value; friend void A::f(); }; X x{}; }; void A::f(){ x.value++; } void A::g(){ //illegal: x.value++; }

On Tuesday, 14 June 2022 at 20:27:23 UTC, deadalnix wrote: > On Tuesday, 14 June 2022 at 05:43:49 UTC, forkit wrote: >> What do you think the cost of adding such a feature is? > > Any cost above 0 is a no go here. > > The feature is useless. If things shouldn't see each other's private, they don't belong in the same module. > > Done, thanks for coming to my TED talk. The argument is useless because it is not even an argument.

On Tuesday, 14 June 2022 at 20:41:35 UTC, Ola Fosheim Grøstad wrote:

On Tuesday, 14 June 2022 at 20:04:14 UTC, Dom Disc wrote:

On Tuesday, 14 June 2022 at 17:24:31 UTC, Ola Fosheim Grøstad wrote:

On Tuesday, 14 June 2022 at 17:16:04 UTC, Dom Disc wrote:

If it's a member, you can do nothing about it - not with module level nor with class level privacy. Also not in C++ or Java or any other language I know about.

Not sure what you meant by this. You can make the member a class that has its own privacy with a selective set of friends.

What I mean is: You cannot prevent a member function from having access to the private variables of the class. Even if it should not touch them.

This seems to compile:

Ok, you got me.
Didn't thought about friends of sub-classes.
But in D I don't know ... maybe something similar is possible?

On Tuesday, 14 June 2022 at 11:12:59 UTC, Dennis wrote: > On Tuesday, 14 June 2022 at 10:54:17 UTC, forkit wrote: >> you mean, like @mustuse ;-) >> >> a 'new' feature that I'll likely *never* have a need to use btw. > > I don't think you have bad intentions, but this comes across as passive-aggresive to me. Just wanted to let you know. My point was, that 'part' of the argument he put forward does not stand up to further scrutiny. Twisting that around to suggest I'm being passive-aggressive, is nonsense.

On Tuesday, 14 June 2022 at 22:26:18 UTC, forkit wrote: > On Tuesday, 14 June 2022 at 11:12:59 UTC, Dennis wrote: >> On Tuesday, 14 June 2022 at 10:54:17 UTC, forkit wrote: >>> you mean, like @mustuse ;-) >>> >>> a 'new' feature that I'll likely *never* have a need to use btw. >> >> I don't think you have bad intentions, but this comes across as passive-aggresive to me. Just wanted to let you know. > > My point was, that 'part' of the argument he put forward does not stand up to further scrutiny. > > Twisting that around to suggest I'm being passive-aggressive, is nonsense. In the link you posted about passive-aggressive behavior, there is the following section: 3. Diverting The Subject. You asked what the cost is of adding a 'private(scope)' feature. Paul then replied about opportunity costs. You then mentioned @mustuse, in a way that could be construed as mildly disparaging regarding it's own opportunity cost, in order dismiss his answer as being valid. Dennis considered this passive-aggressive; he might be wrong, but not nonsensical. Personally, I'm more likely to use 'private(scope)' than @mustuse. I'm also more likely to understand 'private(scope)' better than @mustuse. These two facts have nothing to do with the question "does private(scope) justify the cost". Jordan

June 14, 2022

Re: Adding a new design constraint to D

Posted by forkit
in reply to The Zealot

Permalink

forkit

Posted in reply to The Zealot

Permalink

On Tuesday, 14 June 2022 at 12:00:29 UTC, The Zealot wrote:
>
> I don't think calling it a workaround is even correct.
> _class private_ would actually be the workaround. Just to put multiple classes inside one file that should conceptually not be in the same file in the first place.

why would you "put multiple classes inside one file that should conceptually not be in the same file in the first place. "?

that makes no sense??

Also, I come from a world where if something should be private, you should be able to declare it as private. It's a clear principle in the languages I use.

private is design tool to aid encapsulation, and makes it hard to accidently get it wrong.

it's a feature I use all the time, for (primarily) those reasons just stated.

if that feature we're removed from C#, we'd be in deep shi$. the barrier of encapsulation would be widened, not lessened, and accidental mistakes will occur all the time.

without the feature I'm suggesting, you end up with what you already have in D.

That is, you cannot use private to aid encapsulation *within* a module, nor can you use it prevent you (or others) from getting it wrong. since it doesn't exist!

you have to rely on yourself in D, to 'just not do it' - (it's a C like mentality - which some are truly eager to protect as an important part of the indentity of the D programmer). I get it, but that just doesn't scale very well.

you can't rely on every programmer on your project to 'just not do it'.

The problem, once you want to scale software design, is not 'having' scope level private, it's 'not having it' - and the (primary) problems are as I've highlighted above.

There is no downside to better encapsulation within a module, nor is there any downside to preventing accidental mistakes - unless you want neither of these things.

I'd also like to be able to better enscapsulate ideas that already exist within a module, by being able to spread that module over more than one file. but that's a topic for another thread ;-)

On Tuesday, 14 June 2022 at 23:18:08 UTC, Jordan Wilson wrote: > > In the link you posted about passive-aggressive behavior, there is the following section: 3. Diverting The Subject. > > You asked what the cost is of adding a 'private(scope)' feature. > Paul then replied about opportunity costs. > You then mentioned @mustuse, in a way that could be construed as mildly disparaging regarding it's own opportunity cost, in order dismiss his answer as being valid. yes. I was indeed dismissing a 'part' of his argument as being invalid. but that's because *it was* invalid, and not because I was being passive-aggressive. that is the difference ;-) please review that part of his arguement again.

On Tuesday, 14 June 2022 at 23:31:35 UTC, forkit wrote: > > please review that part of his arguement again. to be specific, it was this part "The main cost is the opportunity cost [1]. Any effort we spend implementing, documenting, debugging, and teaching 'private(scope)' reduces the amount of effort we can spend on other things." That is not a valid argument against private(scope). It an argument against anything. I demonstrated how invalid this part of his argument is, by referring back to @mustuse (his proposal). I need arguments against the idea being proposed, not any idea.

On Tuesday, 14 June 2022 at 23:44:24 UTC, forkit wrote: > > ... > That is not a valid argument against private(scope). > > It an argument against anything. > indeed he acknowledged as such in his response: "Sure, you could make an argument that the effort spent on @mustuse could have been better spent elsewhere."

Forums