On Friday, 18 May 2018 at 12:26:14 UTC, Gheorghe Gabriel wrote:
> Good idea. Or: private(this)
> Because using "this" it is easier tu put this code in a mixin for multiple classes.
> Example:
>
> string var = "private(this) var;";
>
> class A {
>     mixin(var);
> }
>
> class B {
>     mixin(var);
> }

Me like :)

You can have both so you can do what you say with private(this) and also allow access from other classes/structs

class A { private(this, B) onlyForMeAndTypeB; }

Essentially a more fine grained version of C++'s friend.

On Friday, 18 May 2018 at 12:32:30 UTC, Mike Parker wrote:
>
> private(this) int y;
>

I think that might be it. So clean.


> This keeps the implementation simple and the scope focused. If a DIP were put forward, I think this would be the approach to take. Though a fairly strong case will still need to be made as to why this is beneficial (use cases, example code, etc). To bolster the case, I would look at the reasoning behind the recommendation in Java that classes use the public API internally rather than manipulating member variables directly to improve maintainability.

How hard is it to convince people, that being able to have the compiler detect semantic errors that break your defined interface is actually a good thing. I mean really. I've had this capability in major languages for decades.

Let D empower the programmer in this case, by giving that back to them (as an opt-in)

On 5/17/18 10:08 PM, KingJoffrey wrote:
> On Thursday, 17 May 2018 at 14:14:28 UTC, Steven Schveighoffer wrote:
>>
>> D's main draw is not OOP. So if you are here for OOP goodies, then you are definitely better off looking elsewhere.
>>
> 
> I'll add that too my list of D forum quotes.

Awesome, I love being on lists!

> 
>> That being said, D does have OOP, and many OOP programmers are fine with the current state of affairs.
> 
> How many OOP programmers in the world?

Too many.

> How many of them use D?

Only the good ones ;)

> Your use of the word 'many' is questionable.

Many means more than a few.

>> Not disputing that, it's a reasonable choice either way.
> 
> And yet, the D community is intent on not empowering the programmer to make that choice themselves.

I'm not aware of a programming language that lets the user decide what keywords are supposed to mean. If there is one, let me know so I can stay away.

>>
>> Unfortunately, that fails the first time you see code that has "sealed" on it, and have to go figure out what exactly that means.
> 
> That's what happend to me, with the 'D version' of 'private'.

It happened to me too!

https://forum.dlang.org/post/fbs28v$2ss6$1@digitalmars.com

And then I learned how it worked and said "oh, ok, makes sense".

> You can say the same for every other attribute D has, that I had never seen before.
> 
> It's a nonsense argument that many use, to prevent change.

The argument is that it *does* add to the load needed to understand the language, so it better be worth it. It's not a nonsense argument, every extra attribute adds extra cognitive load.

So saying the change would be "blind" to those people who don't care about it is not true. When you see an attribute that you don't understand, you need to look it up to see what it does, it may do something you don't want it to.

>> You're welcome to write a DIP, but I don't see a very good chance for acceptance given the discussions on this subject.
>>
> 
> I agree. The D community is too small, and insufficiently diverse to discuss this any further.

Hm.. I see you are still here arguing though. Interesting.

> It's funny how we build programming languages to serve us, but we end up serving them.

This should go on your quotes list I think. Or maybe a fortune cookie.

-Steve

On Friday, 18 May 2018 at 12:26:14 UTC, Gheorghe Gabriel wrote:
>
> Good idea. Or: private(this)
> Because using "this" it is easier tu put this code in a mixin for multiple classes.

Also, it also removes the redundancy of referring to the actual class name - as in:

private(this) int i; // Nice!

private(yourclassname) int i; // yuk. unneccesary redundancy.

On Friday, 18 May 2018 at 12:51:42 UTC, Steven Schveighoffer wrote:
>
> Awesome, I love being on lists!

Well, just remember to vote *down* the dip then, cause if doesn't get through, your quote be on my list of 'why OOP programmers should not consider D' ;-)

>
> It happened to me too!
>
> https://forum.dlang.org/post/fbs28v$2ss6$1@digitalmars.com
>
> And then I learned how it worked and said "oh, ok, makes sense".
>

How can implicately breaking encapsulation make sense to an OOP programmer?

How can 'I don't care about your defined interface, I'm gunna bypass it' - make sense to an OOP programmer?

Let's be realistic here. The 'one class per module or it all breaks down' model, just won't suit 'many' programmers.


>
> Hm.. I see you are still here arguing though. Interesting.
>

Well, some good ideas (much better than mine) somehow popped up.

So there's hope for D yet.

On Friday, 18 May 2018 at 12:32:30 UTC, Mike Parker wrote:
> private(this) int y;
>
> This keeps the implementation simple and the scope focused.

Yeah, maybe more focused at the beginning would be better. A comma separated list can be added later if deemed worthy.

And agreed, the java recommendation might help build a case. There's also the argument of avoiding state related bugs in larger code bases that is managed through computed properties:

class A {
  @property int i() {
    // fix internal state due to access
    return _i;
  }
  private int _i;
}

Of course these are all solved by putting a class in its own module anyway. I can see this being problematic the bigger code bases get though. I.e. programmer A adds an extension function in module M that is 6000 lines long and doesn't see that he should do A.i and not A._i - bug maybe goes unnoticed for long time.

Only thing I can actually think of is if you want to have extension functions on classes in the same module and only want some variables to be accessible from extension functions but keep other truly private, you can't do this. So it makes writing code in an extension based style harder. But then you can argue if an extension needs to access private(this) variables then it should be module private anyway. So meh...

On Friday, 18 May 2018 at 12:16:55 UTC, aliak wrote:
>
> You may not need a new word at all. You can also enhance private to take arguments. Package already does this. You can give private a symbol list that says which symbols this is private for. So:
>
> class A {
>   private int x;
>   private(A) int y;
> }
> void main() {
>   A a = new A();
>   a.x = 7; // ok, it's private to module
>   a.y = 3; // error, it's sealed to class
> }
>
> Cheers,
> - Ali

Don't really have a stake in the convo, but I'll jump in to say this looks like a solid solution to me (also agree 'this' instead of classname).

On Friday, 18 May 2018 at 12:42:05 UTC, KingJoffrey wrote:

>
> How hard is it to convince people, that being able to have the compiler detect semantic errors that break your defined interface is actually a good thing. I mean really. I've had this capability in major languages for decades.
>
> Let D empower the programmer in this case, by giving that back to them (as an opt-in)

Two points:

1) the status quo in D is not generally viewed as a violation of encapsulation (if you change the class, you can also change the module)

2) there's a simple workaround already in place for people who really, really, want to do it

The DIP will need to provide counters to both of these points. One example for point one off the top of my head --

Currently, if you do something like change the name of a private member, anything in the module still referencing the old symbol will cause a compiler error and you can fix it immediately.

But, say you have this code:

```
class Foo {
   private int _x;
   int x { return _x; }
}

void printFoo(Foo f) { writeln("Foo: ", f._x);
```

And later, you decide you want to track all accesses to _x in a foo instance:

```
class Foo {
   private int _x;
   private int _xHits;
   int x() {
      ++_xHits;
      return _x;
}

// Oops!
void printFoo(Foo f) { writeln("Foo: ", f._x);
```

This would only manifest itself at runtime and in a large module could be one of those bugs that keeps you scratching your head for much longer than it ought to. The same thing can happen through accessing _x internally in the class, but the surface area is smaller and the bug could (theoretically) be caught more quickly (and preventing even this is the rationale behind the Java style of using accessors internally).

So that's the sort of thing a DIP would need to be doing. Essentially, answering the questions: what are the holes in the status quo ("encapsulation is violated" doesn't cut it -- solid examples of real issues are required), and how is the proposed solution superior to the workaround?

On Friday, 18 May 2018 at 12:26:14 UTC, Gheorghe Gabriel wrote:

> Good idea. Or: private(this)
> Because using "this" it is easier tu put this code in a mixin for multiple classes.
> Example:
>
> string var = "private(this) var;";
>
> class A {
>     mixin(var);
> }
>
> class B {
>     mixin(var);
> }

As clean and uncontroversial as this proposal might be, it unfortunately doesn't resolve the biggest issue. If you try to write Java code in D, you're still going to be using private, and you're still going to be caught by surprise. And this is another step in the direction of C++ (we need to think of beginning programmers every so often) so there are costs. It's possible that since I rarely use classes I'm not seeing the large benefits.

On Friday, 18 May 2018 at 14:32:33 UTC, bachmeier wrote:
>
> As clean and uncontroversial as this proposal might be, it unfortunately doesn't resolve the biggest issue. If you try to write Java code in D, you're still going to be using private, and you're still going to be caught by surprise.

This is simply unavoidable - and, that 'surprise' you mention, is already there - it's not dependent on, or in any way related, to any proposal that might result from this discussion.

The D 'private is really public in a module' concept, is here to stay (sadly, but it's true).


> And this is another step in the direction of C++ (we need to think of beginning programmers every so often) so there are costs. It's possible that since I rarely use classes I'm not seeing the large benefits.

C++ is a complex beast, as a result of both needing to accomodate change (evolve), and not wanting to break backwards compatability.

It's still *the* most powerful and flexible tool available for programmers.

Beginner programmers would do well to keep that in mind.

A class is just an abstract type, a tool for those that think it is useful in the solution for their problem domain.

In any case, this discussion is not about convincing you of the value of classes - you should already know that if you are programmer.

This discussion (at least my reason for being involved in it) is about breaking this idiotic (in my opinion) concept that D enforces on 'everyone' - i.e the one class per module, or everything is public, and you have no say in it.

I don't necessarily object to the freedom the D module provides (i.e to bypass your interfaces, even accidently). What I object to is the 'i.e the one class per module, or everything is public, and you have no say in it.'

A proposal that empowers the programmer to use the module for more than just a container for single class, coupled with static compile time verification - i.e you can't accidently access your private(this) T as it would be a compile time error, would be good for D (in my opinion), because those that have enjoyed having this capability in other mainstream langauges for literally decades!, won't be shut out from using D.

It will attract more programmers, not less - and trust me, D better get more programmers using it, cause 18 years on, and it hasn't got that far, really.

To get more programmers, you might want to be more open to accomodating their needs too.

Although I do wonder, sometimes, whether the aim if D is just to be this cosy little langauge that not many use, except for those that do.