On Thursday, 17 May 2018 at 07:58:55 UTC, KingJoffrey wrote:
> Remember, the idea for discussion is about adding one single attribute 'sealed' to the class - the discussion is a lot less about 'how can we prevent having to add a this new attribute'.

It is normal, whenever someone suggests changing the language, to talk about alternatives that don't involve changing the language. We can't properly discuss how important a change is without going through the existing ways to solve the problem.

If I proposed a change, or if Walter or Andrei did, we'd have the same sorts of discussion.

Do you think you should be exempt?

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.

> 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?

How many of them use D?

Your use of the word 'many' is questionable.

>
> 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.


>
> 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'.

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.


>
> That's not what was stated. This proposal is a convenience feature, because you can already accomplish what is requested (making sure private internals are inaccessible to certain parts of the code). At this point, making incremental changes like this requires a very high bar of acceptance since you would be adding another complication to a language that is fairly stable. If I were you, I would stop worrying about this and either accept the status quo or look for a language that suits your requirements more directly. I think there are probably no people here who think D is the "perfect language", or that there even exists a "perfect language", you just have to judge whether the warts are worth living with or not.
>
> You're welcome to write a DIP, but I don't see a very good chance for acceptance given the discussions on this subject.
>
> -Steve

I agree. The D community is too small, and insufficiently diverse to discuss this any further.

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

On Friday, 18 May 2018 at 02:08:47 UTC, KingJoffrey wrote:
> On Thursday, 17 May 2018 at 14:14:28 UTC, Steven Schveighoffer wrote:
>>
>> You're welcome to write a DIP, but I don't see a very good chance for acceptance given the discussions on this subject.
>>
>> -Steve
>
> I agree. The D community is too small, and insufficiently diverse to discuss this any further.
>
> It's funny how we build programming languages to serve us, but we end up serving them.

FFS you're so dramatic. First the world is ending because private doesnt work as you expected. Then D is utterly useless without the changes you want. Now we live in some dystopian nightmare where we are all slaves to the Dlang spec.

Listen up dude, people here have been using D as it is, are happy with how it works, and even prefer how it works. They have done so for months or years. That is a big bar for you to get over, they have years of experience with D working for them. Coming in and saying "ooh but thats wrong, your doing it wrong.. because OOP... etc..." waving your arms, making hyperbolic statements about how its the end of the world etc... wont win any arguments.

You cant convince people of what you say if all you do is give them an ideological*** argument that is counter to their years of experience. That's just the way it is, it's actually better that way, because otherwise people would be swayed by every passing preacher and everything would be in a right mess.

***Your argument is ideological because you dont provide any evidence for it. This has been pointed out and yet you still dont seem grasp it. Saying "this is what you need to do and this is why it will benefit" is not evidence, it is a statement of belief.

Please understand I am not saying what you want is right or wrong, I'm saying you dont understand why people aren't won over by what you say.

On Friday, 18 May 2018 at 09:07:57 UTC, Dave Jones wrote:
>
> FFS you're so dramatic. First the world is ending because private doesnt work as you expected. Then D is utterly useless without the changes you want. Now we live in some dystopian nightmare where we are all slaves to the Dlang spec.
>
> [..dadadadadaaaaa...]

Thanks Dave.

You make my case  (i.e. The D community is too small, and insufficiently diverse to discuss this any further.)

Except, that I'd add to that, that far too many are pretty immature too.

Good luck with your dlang thing...18+ years old and still < 1000 programmers (perhaps a lot less). (and if you have more than one class in a file, you have no more encapsulation - I love it).

On Friday, 18 May 2018 at 11:41:33 UTC, KingJoffrey wrote:
> ..

I should have also added:

good luck rememebering to use private, cause public is default (ha haa haaa).

then again, private is public, so I guess it doesn't matter.

enjoy those debugging sessions...

On Thursday, 17 May 2018 at 02:32:07 UTC, KingJoffrey wrote:
> I propose an idea, for discussion (robust discussion even better ;-)
>
> Add an new attribute to class, named 'sealed'.
>
> No, not sealed as in Scala.
>
> No, not sealed as in C#
>
> sealed as in oxford dictionary (close securely, non-porous).
>
> when sealed is applied on the class, this means the class is sealed.
>
> the sealed attribute only makes sense within a module, and affects nothing outside of the module.
>
> When sealed is applied to the class, then, interfacing to a class within a module, from code outside that class - but still within the module, can now only occur via the published interface of the class.
>
> outside code in the module, can no longer directly access your private parts!
>
> The class is sealed.

I think this code has cleaner sintax:

class A {
    private int x;
    sealed 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
}

On Friday, 18 May 2018 at 12:00:58 UTC, Gheorghe Gabriel wrote:
> On Thursday, 17 May 2018 at 02:32:07 UTC, KingJoffrey wrote:
>> I propose an idea, for discussion (robust discussion even better ;-)
>>
>> Add an new attribute to class, named 'sealed'.
>>
>> No, not sealed as in Scala.
>>
>> No, not sealed as in C#
>>
>> sealed as in oxford dictionary (close securely, non-porous).
>>
>> when sealed is applied on the class, this means the class is sealed.
>>
>> the sealed attribute only makes sense within a module, and affects nothing outside of the module.
>>
>> When sealed is applied to the class, then, interfacing to a class within a module, from code outside that class - but still within the module, can now only occur via the published interface of the class.
>>
>> outside code in the module, can no longer directly access your private parts!
>>
>> The class is sealed.
>
> I think this code has cleaner sintax:
>
> class A {
>     private int x;
>     sealed 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
> }

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

On Friday, 18 May 2018 at 12:16:55 UTC, aliak wrote:
> On Friday, 18 May 2018 at 12:00:58 UTC, Gheorghe Gabriel wrote:
>> On Thursday, 17 May 2018 at 02:32:07 UTC, KingJoffrey wrote:
>>> [...]
>>
>> I think this code has cleaner sintax:
>>
>> class A {
>>     private int x;
>>     sealed 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
>> }
>
> 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

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);
}

On Friday, 18 May 2018 at 12:00:58 UTC, Gheorghe Gabriel wrote:
>
> I think this code has cleaner sintax:
>
> class A {
>     private int x;
>     sealed 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
> }

I agree. I actually like your solution much better, and, it's less likely to cause confusion with use of the word 'sealed', because it's applied to the variable (and therefore people from other languages won't get confused having sealed applied at the class level - unless there are languages that applye sealed at the variable level).

Now, you write that DIP (that everyone will ignore).

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
> }
>

That's actually a decent way to go about it. It matches the package syntax and avoids new keywords. It's also not as onerous as repurposing an existing keyword (like `module`), nor does it cause any breakage. Though, I would argue that rather than allowing any old symbol, it be restricted to `this`:

private(this) int y;

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.