www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Sealed classes - would you want them in D? (v2)

reply KingJoffrey <KingJoffrey KingJoffrey.com> writes:
I propose an idea, for discussion (robust discussion even better 
;-)

Add an new attribute to class, named 'sealed'.

No, not sealed as in Scala.



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.
May 16 2018
next sibling parent KingJoffrey <KingJoffrey KingJoffrey.com> writes:
On Thursday, 17 May 2018 at 02:32:07 UTC, KingJoffrey wrote:

 I propose an idea, for discussion (robust discussion even 
 better ;-)  ....


oh, and it would be great, if the D 'elite' could way in to the 
discussion as well, as opposed to only waying in *after* a DIP is 
put forward.

All ideas would be helpful, including how complex it 'might' be 
to implement (compiler people).

Would it, or could it, break compatability - in any 
way..etc.etc...
May 16 2018
prev sibling next sibling parent reply Neia Neutuladh <neia ikeran.org> writes:
Can you provide even one anecdote where this would have been 
useful and the workaround that has been suggested to you multiple 
times (putting the type in its own module) wouldn't have worked 
or would have caused other problems?

I mean, usually we need to do a cost/benefit analysis, and the 
first part of that, the one that people generally do 
instinctively, is try to describe the benefit. You seem to view 
the benefit as self-evident, but we've told you many times that 
it isn't self-evident to us, so you have more work to do if you 
want to convince anyone.

If you just want to vent, though, you might say that explicitly.
May 16 2018
next sibling parent KingJoffrey <KingJoffrey KingJoffrey.com> writes:
On Thursday, 17 May 2018 at 04:01:11 UTC, Neia Neutuladh wrote:

 If you just want to vent, though, you might say that explicitly.


This is hardly a great way to start the discussion.

When I said robust, I meant useful too.
May 16 2018
prev sibling next sibling parent KingJoffrey <KingJoffrey KingJoffrey.com> writes:
On Thursday, 17 May 2018 at 04:01:11 UTC, Neia Neutuladh wrote:

 Can you provide even one anecdote where this would have been 
 useful and the workaround that has been suggested to you 
 multiple times (putting the type in its own module) wouldn't 
 have worked or would have caused other problems?


My opening discussion outlines what I want, very very clearly.

The hack you mention, is not what I am asking for in my opening 
discussion.

Please go back and read my opening discussion properly.
May 16 2018
prev sibling next sibling parent KingJoffrey <KingJoffrey KingJoffrey.com> writes:
On Thursday, 17 May 2018 at 04:01:11 UTC, Neia Neutuladh wrote:

 so you have more work to do if you want to convince anyone.


Again, a reminder, this is not a DIP. It's *just* a discussion.

The purpose of the discussion is not necessarly to convince 
anyone, of anything.

The purpose of the discussion is to gather peoples views, 
thoughts, ideas, concerns.....
May 16 2018
prev sibling parent reply KingJoffrey <KingJoffrey KingJoffrey.com> writes:
On Thursday, 17 May 2018 at 04:01:11 UTC, Neia Neutuladh wrote:

 I mean, usually we need to do a cost/benefit analysis, ...


The benefit is explained in my opening discussion.

That is, i can have more than just a single class in a module 
file, as still be able to 'program to the interface' of the 
class, rather than implicitely give all other code in that module 
access to the private parts of my class.

Programming to the interface, is clear design philosophy of mine. 
Which is why I actually like the C++ friend attribute - because 
that is an explicit part of the defined interface.

An additional benefit is, that a class not marked as sealed (in a 
module), is a warning sign that anything else in the module (but 
outside of the class), may ignore the your class interface (i.e. 
can access it's private parts). So it could be helpful attribute 
for the way in which you approach analysing the code within the 
module.

For me, personally, I see this as a benefit. I do not see any 
downside (from a user perspective).

It does not change the benefit others get from having the status 
quo - which would remain unaffected - and while the status quo 
does indeed have benefits (as I've discovered in the other 
thread), it also has retains the downside of other local code in 
the module being able to bypass a declared interface.

If people want to propose putting each class in it's own module, 
that does not address my requirements, and therefore is not 
helpful to this discussion.
May 16 2018
parent reply arturg <var.spool.mail700 gmail.com> writes:
On Thursday, 17 May 2018 at 05:06:54 UTC, KingJoffrey wrote:

 If people want to propose putting each class in it's own 
 module, that does not address my requirements, and therefore is 
 not helpful to this discussion.


you could declare the public api of your class inside an actual 
interface then use it instead of the class, that wont give you 
access to the private members of the class.
May 16 2018
parent reply KingJoffrey <KingJoffrey KingJoffrey.com> writes:
On Thursday, 17 May 2018 at 06:03:19 UTC, arturg wrote:

 you could declare the public api of your class inside an actual 
 interface then use it instead of the class, that wont give you 
 access to the private members of the class.


you mean like this?

--------------------
module test;

interface Animal { string makeNoise(); }

class Dog : Animal
{
     private string noiseType = "woof";

     override string makeNoise()
     {
         return this.noiseType;
     }
}

void main()
{
     import std.stdio;

     auto dog = new Dog;
     dog.noiseType = "meow"; // grr!
     writeln(dog.makeNoise()); // wtf! Thanks to D, my dog can now 
meow!
}

--------------------
May 17 2018
parent reply arturg <var.spool.mail700 gmail.com> writes:
On Thursday, 17 May 2018 at 07:30:58 UTC, KingJoffrey wrote:

 On Thursday, 17 May 2018 at 06:03:19 UTC, arturg wrote:

 you could declare the public api of your class inside an 
 actual interface then use it instead of the class, that wont 
 give you access to the private members of the class.


 you mean like this?

 --------------------
 module test;

 interface Animal { string makeNoise(); }

 class Dog : Animal
 {
     private string noiseType = "woof";

     override string makeNoise()
     {
         return this.noiseType;
     }
 }

 void main()
 {
     import std.stdio;

     auto dog = new Dog;
     dog.noiseType = "meow"; // grr!
     writeln(dog.makeNoise()); // wtf! Thanks to D, my dog can 
 now meow!
 }

 --------------------


no, that uses type inferance.
you have to do
Animal dog = new Dog;
May 17 2018
parent reply KingJoffrey <KingJoffrey KingJoffrey.com> writes:
On Thursday, 17 May 2018 at 07:36:40 UTC, arturg wrote:

 no, that uses type inferance.
 you have to do
 Animal dog = new Dog;


i tried it... certainly interesting.. thanks.

but, I don't recall in my opening post, saying I'm ok with having 
to create an interface for every class I create, just so I can go 
off and cast each class to that interface ;-)

The sealed attribute would not require me to go to such 
extravagant lengths.

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'.
May 17 2018
parent Neia Neutuladh <neia ikeran.org> writes:
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?
May 17 2018
prev sibling next sibling parent reply Zoadian <no no.no> writes:
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'.


If class level protection is added, please do not call it sealed.
People from c++ might be suprised by 'private' already. We do not 
have to confuse those c#ies too.

Module level protection is enough to hide implementation details 
though. So while i do understand why you want this in D, i don't 
think it is worth it to complicate the language for something you 
can work around easily by putting the classes in their own 
modules.
I'm also not convinced think that your 'sealed' would be used 
much, because accessing private state in the module is actually 
extremly useful (e.g. unittests).

That beeing said, if you are convinced it would be a good 
addition, please write a DIP.
Even if it will not be accepted it will at least force a 
decision. And we can point to the reasons it got 
accepted/rejected in the future.
May 17 2018
next sibling parent reply KingJoffrey <KingJoffrey KingJoffrey.com> writes:
On Thursday, 17 May 2018 at 10:34:18 UTC, Zoadian 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'.


 If class level protection is added, please do not call it 
 sealed.
 People from c++ might be suprised by 'private' already. We do 
 not have to confuse those c#ies too.


Interesting.

If only D had applied that same criteria to use of the word 
'private'.

I do wonder what word could possibly suffice, to please everyone.



 Module level protection is enough to hide implementation 
 details though. So while i do understand why you want this in 
 D, i don't think it is worth it to complicate the language for 
 something you can work around easily by putting the classes in 
 their own modules.


Here, I think you are falling into the trap, of believing, that 
the concept of
modularity can only ever apply the way D currently applies it - 
at the file level.

In OOP programming, the class is the module. (yes, I know how 
much D programmers love OOP ;-)

When OOP programmers come to D however, they are 'forced' into 
the D concept of modularity, and cannot model modularity in 
accordance with their own problem domain - but have no choice to 
use one class per file - just to regain what they already have in 
other mainstream languages. But then, for those OOP programmer, 
the 'file' has little value, cause it now can only ever represent 
a single class.

Remember, that the idea here is not to force anyone to change how 
they currently think or do things. It simply extends the way in 
which a 'file' module can be used.



 I'm also not convinced think that your 'sealed' would be used 
 much, because accessing private state in the module is actually 
 extremly useful (e.g. unittests).


Again, what people can do, they will still be able to do. Nothing 
changes for them.

btw. D has less than 1000 programmers. How many OOP programmers 
in the world?
Build it, and they will come...perhaps.


 That beeing said, if you are convinced it would be a good 
 addition, please write a DIP.


DIP before discussion, is not the way I do things.


 Even if it will not be accepted it will at least force a 
 decision. And we can point to the reasons it got 
 accepted/rejected in the future.


Again, DIP before discussion, and we all know what will happed to 
the DIP.
May 17 2018
parent Uknown <sireeshkodali1 gmail.com> writes:
On Thursday, 17 May 2018 at 11:18:52 UTC, KingJoffrey wrote:

 On Thursday, 17 May 2018 at 10:34:18 UTC, Zoadian wrote:

 On Thursday, 17 May 2018 at 02:32:07 UTC, KingJoffrey wrote:

 [...]


 People from c++ might be suprised by 'private' already. We do 
 not have to confuse those c#ies too.


 Interesting.

 If only D had applied that same criteria to use of the word 
 'private'.


Have you considered the keyword `module`?

--- kings.d
class King
{
     private string _name;
     module string __name;
     public string getName()
     {
         return __name;
     }
     public void setName(string name)
     {
         __name = name;
     }
}

void main()
{
     scope king = new King();
     king._name = "me"; //ok: _name is private
     king.__name = "me"; //error: __name is of `module` scope
     king.setName("me"); //ok
}


 I do wonder what word could possibly suffice, to please 
 everyone.


`module`

/s

 [...]


 Again, DIP before discussion, and we all know what will happed 
 to the DIP.


I won't oppose such an addition since it will be purely opt-in, 
but you will have to consider that this would add more specifiers:
`private`, `protected`, `package`, `public` and `export`.
You might also want to read these [0] past discussions on this 
feature. I'm not sure how up to date that doc is, but it should 
be a good starting point.

[0]: 
https://wiki.dlang.org/Access_specifiers_and_visibility#Current_state_of_affairs_in_C.2B.2B
May 17 2018
prev sibling parent reply 0xEAB <desisma heidel.beer> writes:
On Thursday, 17 May 2018 at 10:34:18 UTC, Zoadian wrote:

 If class level protection is added, please do not call it 
 sealed.
 People from c++ might be suprised by 'private' already. We do 
 not have to confuse those c#ies too.


I thought the same.



 Module level protection is enough to hide implementation 
 details though. So while i do understand why you want this in 
 D, i don't think it is worth it to complicate the language for 
 something you can work around easily by putting the classes in 
 their own modules.


I wouldn't consider putting classes into own modules a 
workaround. In my opinion it's more or less the solution.
May 19 2018
next sibling parent KingJoffrey <KingJoffrey KingJoffrey.com> writes:
On Saturday, 19 May 2018 at 21:25:37 UTC, 0xEAB wrote:

 On Thursday, 17 May 2018 at 10:34:18 UTC, Zoadian wrote:

 If class level protection is added, please do not call it 
 sealed.
 People from c++ might be suprised by 'private' already. We do 
 not have to confuse those c#ies too.


 I thought the same.



 Module level protection is enough to hide implementation 
 details though. So while i do understand why you want this in 
 D, i don't think it is worth it to complicate the language for 
 something you can work around easily by putting the classes in 
 their own modules.


 I wouldn't consider putting classes into own modules a 
 workaround. In my opinion it's more or less the solution.


Requiring such a restrictive 'solution', just to protect your 
interface from human error, is a solution for some, and not 
others.

open your mind a little.
May 19 2018
prev sibling parent KingJoffrey <KingJoffrey KingJoffrey.com> writes:
On Saturday, 19 May 2018 at 21:25:37 UTC, 0xEAB wrote:

 I wouldn't consider putting classes into own modules a 
 workaround. In my opinion it's more or less the solution.


I'll add your solution into my article - but, I'm not sure it 
really addresses my problem statement.

The Problem Statement (being drafted still):
---------------------
In the D programming language, the semantics of the access-level 
modifier 'private' is likely very different to what a large 
number of programmers from object-oriented, and class-oriented 
languages, might expect.

In D, the module (not the class) is the overarching entity, and 
one that encompasses all other entities within the module.

In D, The module can contain (and typically would contain) a 
variety of types - functions, structs, classes and so on.

If a module contains a class type however, and that class has a 
private access modifier on it's members, then that private access 
modifier becomes moot (within the module), because all the 
surrounding code in that module can directly access (and even 
modify) those private members.

The module implicitly morphs a 'private' access modifier, into a 
'private-but-also-module-public' modifier.

The programmer has no control over this implicit conversion of 
the access modifier.

This would be unfamiliar, and unexpected, to a very large number 
of programmers from languages where 'private' has an established 
and well-defined semantic as being the most restrictive form of 
access to a class member.

Unfortunately, in the D programming language, there is simply no 
way to declare a member of a class to be private, and prevent 
surrounding code (within the module) from accessing it.

The D module, will implicitly change the semantics of your code.


The Implications:
----------------
..to do....
May 20 2018
prev sibling next sibling parent reply Piotr Mitana <the.mail.of.mi2 gmail.com> writes:
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.



 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.



has its sealed and Scala has its sealed - and these are different 


"sealed" keyword yet another sense in D is not the right approach.

Furthermore, I don't believe that the proposed version of sealed 
would be a widely-used feature that broadens the language 
capabilities. It solves the problem that - as discussion in my 
thread shown - some people consider valid, and some not.

My opinion is that it's not worth a new keyword and time for 
implementing. In the same manner you could ask for removing 
friend concept from C++ as a bad concept. I don't answer the 
question whether this concept is good or bad - just give an 
example. The difference is that you can just go without friend at 
all, and module-level private is forced.

The other reason I don't think it is a feature significant enough 
is kind of library level. I expect that only author or limited 
team of people will freely modify the code of module. So there is 
limited number of people that have a control over the module and 
it shouldn't be a big deal not to refer to private fields outside 
the class or define it as a team rule. I believe that a nice 
approach here would be to add a check to DScanner, so that your 
editor or IDE could optionally warn you if you refer to the 
private member from outside the class. But as module is a small 
unit and its code should probably be controlled/verified by the 
limited number of people, I don't see this as a big deal.

Note that Scala-like sealed from my proposal would have a greater 
impact (it blocks inheritance outside the module - helps to 
prevent the library code from being used in a way it is not 
designed to) and your proposal changes things in a very limited 
scope.

OFC, I am not a "compiler person", nor Walter, Andrei and anyone 
from the team, so my opinion is definitely not decisive in any 
way :)

To sum up [TLDR]: I don't see your arguments strong enough to 
alter the language (especially make a cross-language confusion 
over the "sealed" keyword), but DScaner check would still allow 
to track down what you consider bad.
May 17 2018
next sibling parent KingJoffrey <KingJoffrey KingJoffrey.com> writes:
On Thursday, 17 May 2018 at 11:56:51 UTC, Piotr Mitana wrote:

 My opinion is that it's not worth a new keyword and time for 
 implementing. In the same manner you could ask for removing 
 friend concept from C++ as a bad concept. I don't answer the 
 question whether this concept is good or bad - just give an 
 example. The difference is that you can just go without friend 
 at all, and module-level private is forced.


Try telling Bjarne Stroustrup that ;-)

I still believe (like Bjarne) that friend in c++ is the right 
way, for those of us that believe that the defined interface is 
how you obtain your interface. Friend is a part of the defined 
interface.

Within implict friends, the interface is pretty blurry - but 
that's another story, and as I said, my change would not affect 
those who thing facebook like friendship in modules is a good 
approach - I think we can have it both ways really.

Although I don't suggest adding friend to D, I do like option of 
having static enforcement of the defined interface, as a 
possibilty the programmer can opt-in to.

At the moment, that can only be done by the one-class-per-module 
hack.

Which means, for OOP programmers, the module in D(i.e. the file), 
becomes nothing more than a pseudo class. This will make some 
(perhaps many) OOP programmers wonder why they should bother 
coming to D at all. It certainly is a question I keep asking 
myself, over and over - at some point I make a conclusion.

The capacity to have more than one class in a module, and be able 
to obtain static enforcement of the use of the defined interface 
(by restoring private to its rightful status - as an option - 
perhaps by the using the sealed attribute on a class), can only 
have a positive effect, in my view. I cannot see how it would 
negatively affect anyone. It's purely opt-in, not opt-out.

And yes, it's a small change, but has potential for great impact 
(presumably, only positive impact) - although that's why I want 
to have this discussion - to see how others think too.
May 17 2018
prev sibling parent KingJoffrey <KingJoffrey KingJoffrey.com> writes:
On Thursday, 17 May 2018 at 11:56:51 UTC, Piotr Mitana wrote:

 To sum up [TLDR]: I don't see your arguments strong enough to 
 alter the language (especially make a cross-language confusion 
 over the "sealed" keyword), but DScaner check would still allow 
 to track down what you consider bad.


'altering' the langauge is a pretty strong way to describe it.

I prefer to think of it as 'empowering the programmer'.

Now, choosing a keyword, will certainly be tricky, I accept that 
much. There is little consenus going to happen there, I guess.

As for your dscanner solution, that doesn't address the 
requirement.

And in any case, should D programmers have to rely on dscanner to 
pick up the problem with this?

----
module test;

void main()
{
     int var = 1;
     const int *ip = &var;

     int var2 = 2;
     ip = &var2;
}

------
May 17 2018
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 5/16/18 10:32 PM, 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.
 

 
 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 don't think you are going to get this to fly. We already have 
abilities to make the details truly private. I agree it's not as 
straightforward as other languages, but it is possible. Lately, the 
chances of adding an enhancement like this is pretty slim -- we have a 
mechanism to do it already, but is just a little more clunky. And it's 
not a huge problem for most code. I'd predict that if this were to be 
accepted, it would seldom be used anyway. So the cost/benefit ratio is 
very high.

Essentially, if you put your class you want "sealed" into it's own 
module, and then publicly import the module from the API module, you 
will get the same effect. This is even easier now with the package 
module than it used to be.

What private currently does is rational and makes sense. It's not the 
same as all other languages, but it is the same as some of them. It's 
simply a preference, and D picked something different from what you 
like. There are things I would have picked differently than D also, but 
not much to be done about those choices at this point.

-Steve
May 17 2018
parent reply KingJoffrey <KingJoffrey KingJoffrey.com> writes:
On Thursday, 17 May 2018 at 13:28:19 UTC, Steven Schveighoffer 
wrote:

 Essentially, if you put your class you want "sealed" into it's 
 own module, and then publicly import the module from the API 
 module, you will get the same effect. This is even easier now 
 with the package module than it used to be.


Fair enough. Now no OOP programmer has any need to take at look 
at D.

I can already do that in other, better known, better supported 
languages.

Indeed, i can put more than one class in a class file in those 
languages, and, I still get the guarantee of correctness at 
compile time.


 What private currently does is rational and makes sense. It's 
 not the same as all other languages, but it is the same as some 
 of them. It's simply a preference, and D picked something 
 different from what you like. There are things I would have 
 picked differently than D also, but not much to be done about 
 those choices at this point.

 -Steve


The other persepective is also rational, and makes sense.

I believe both perspectives could be accomodated, and at the same 
time without breaking anything, and without affecting in any way, 
the way people currently use the module.

The change would be completely blind to those people, until they 
choose to opt in to the change.

If D is at the point where change can no longer occured, it's 
over for D.
May 17 2018
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 5/17/18 9:38 AM, KingJoffrey wrote:

 On Thursday, 17 May 2018 at 13:28:19 UTC, Steven Schveighoffer wrote:

 Essentially, if you put your class you want "sealed" into it's own 
 module, and then publicly import the module from the API module, you 
 will get the same effect. This is even easier now with the package 
 module than it used to be.


 
 Fair enough. Now no OOP programmer has any need to take at look at D.

 I can already do that in other, better known, better supported languages.


D's main draw is not OOP. So if you are here for OOP goodies, then you 
are definitely better off looking elsewhere.

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


 What private currently does is rational and makes sense. It's not the 
 same as all other languages, but it is the same as some of them. It's 
 simply a preference, and D picked something different from what you 
 like. There are things I would have picked differently than D also, 
 but not much to be done about those choices at this point.


 
 The other persepective is also rational, and makes sense.


Not disputing that, it's a reasonable choice either way.


 I believe both perspectives could be accomodated, and at the same time 
 without breaking anything, and without affecting in any way, the way 
 people currently use the module.
 
 The change would be completely blind to those people, until they choose 
 to opt in to the change.


Unfortunately, that fails the first time you see code that has "sealed" 
on it, and have to go figure out what exactly that means.


 If D is at the point where change can no longer occured, it's over for D.


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
May 17 2018
parent reply KingJoffrey <KingJoffrey KingJoffrey.com> writes:
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.
May 17 2018
next sibling parent reply Dave Jones <dave jones.com> writes:
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.
May 18 2018
parent reply KingJoffrey <KingJoffrey KingJoffrey.com> writes:
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).
May 18 2018
next sibling parent KingJoffrey <KingJoffrey KingJoffrey.com> writes:
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...
May 18 2018
prev sibling parent Dave Jones <dave jones.com> writes:
On Friday, 18 May 2018 at 11:41:33 UTC, KingJoffrey wrote:

 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're welcome Joffers.



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


You just reinforce the case that you have a tendency to drama and 
hyperbole.



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


I'd rather be pretty and immature than young and stupid.



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


Oh here we go again... if people don't genuflect to Joffer's 
kingly wisdom he storms out like a pouty little tyrant muttering 
"good luck with your crappy language.. hhmmmppff idiots"
May 18 2018
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
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
May 18 2018
parent KingJoffrey <KingJoffrey KingJoffrey.com> writes:
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.
May 18 2018
prev sibling next sibling parent reply Gheorghe Gabriel <knoppy273 live.com> writes:
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.



 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
}
May 18 2018
next sibling parent reply aliak <something something.com> writes:
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.



 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
May 18 2018
next sibling parent reply Gheorghe Gabriel <knoppy273 live.com> writes:
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);
}
May 18 2018
next sibling parent aliak <something something.com> writes:
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.
May 18 2018
prev sibling next sibling parent KingJoffrey <KingJoffrey KingJoffrey.com> writes:
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.
May 18 2018
prev sibling parent reply bachmeier <no spam.net> writes:
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.
May 18 2018
parent reply KingJoffrey <KingJoffrey KingJoffrey.com> writes:
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.
May 18 2018
next sibling parent reply bachmeier <no spam.net> writes:
On Friday, 18 May 2018 at 15:40:52 UTC, KingJoffrey wrote:


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


I'm not saying I oppose making this change, but "evolution of the 
language" takes the form of adding features but never eliminating 
any. If I see

class A {
    private int x;
    private(this) int y;
}

it kind of makes my head hurt, and I've been using D for five 
years. The justification I've seen for complications like private 
vs public is that it's necessary for large programs. There's 
something wrong if a single module is considered large.

Unlike most of the people that post here, I work with beginning 
programmers. In almost all cases, decisions are made on the basis 
of appeal to 20-year C++ veterans, but at least I can say I 
raised the issue.
May 18 2018
next sibling parent reply Gheorghe Gabriel <knoppy273 live.com> writes:
On Friday, 18 May 2018 at 15:57:06 UTC, bachmeier wrote:

 On Friday, 18 May 2018 at 15:40:52 UTC, KingJo

 class A {
    private int x;
    private(this) int y;
 }


I agree that this looks a bit strange.
My initial proposal was "sealed" instead "private(this)" today.
May 18 2018
next sibling parent reply KingJoffrey <KingJoffrey KingJoffrey.com> writes:
On Friday, 18 May 2018 at 16:24:24 UTC, Gheorghe Gabriel wrote:

 On Friday, 18 May 2018 at 15:57:06 UTC, bachmeier wrote:

 On Friday, 18 May 2018 at 15:40:52 UTC, KingJo

 class A {
    private int x;
    private(this) int y;
 }


 I agree that this looks a bit strange.
 My initial proposal was "sealed" instead "private(this)" today.


Mmm.. that brings me back to the idea of sealed at the class 
level again.

class A
{
    private int x;
    private(this) int y;  // imagine if you have lots of private 
variables.
                          // this could become pretty anoying - 
and kinda redundant.
}

class A
{
    private int x;
    sealed int y; // again, what if you have lots of private 
variables that
                  // that you really want sealed.
}


// Now. Back to the idea of sealed.
// abosolute consistency of your private variables.
// no redundancy.
// no some 'private', some 'sealed' confusion.
// no some 'private' (but really public) some 'private(this) .. 
confusion.
//
sealed class A{
     private int x;
     private int y;
}

downside, is adding a new keyword, and getting agreement on what 
that new keyword should be.

So I've come full circle again, and believe my idea is worth 
further consideration.
May 18 2018
next sibling parent reply KingJoffrey <KingJoffrey KingJoffrey.com> writes:
On Saturday, 19 May 2018 at 04:01:18 UTC, KingJoffrey wrote:

 So I've come full circle again, and believe my idea is worth 
 further consideration.


how about this (use a proper annotation).

This will be less likely to confuse anyone from other languages.

e.g

-------------------
module test;

 safeinterface class Dog
{
     private string noiseType = "woof";

     public string makeNoise()
     {
         return this.noiseType;
     }
}

void main()
{
     import std.stdio;

     auto dog = new Dog;
     dog.noiseType = "meow"; // no way jose - requires use of the 
safe interface!
     writeln(dog.makeNoise()); // phew! cause dogs can only bark.
}
-------------------
May 19 2018
parent reply Uknown <sireeshkodali1 gmail.com> writes:
On Saturday, 19 May 2018 at 07:57:39 UTC, KingJoffrey wrote:

 On Saturday, 19 May 2018 at 04:01:18 UTC, KingJoffrey wrote:

[...]


 ----------------
 module test;

  safeinterface class Dog
 {
     private string noiseType = "woof";

     public string makeNoise()
     {
         return this.noiseType;
     }
 }

 void main()
 {
     import std.stdio;

     auto dog = new Dog;
     dog.noiseType = "meow"; // no way jose - requires use of 
 the safe interface!
     writeln(dog.makeNoise()); // phew! cause dogs can only bark.
 }
 -------------------


I ported your example to Java. Surprisingly, it compiled and 
executed just fine:

--- test.java
class test
{
	static class Dog
	{
		private String noiseType = "woof";

		public String makeNoise()
		{
			return this.noiseType;
		}
	}

	public static void main(String[] args)
	{
		Dog dog = new Dog();
		dog.noiseType = "meow"; // no way jose - requires use of the 
safe interface!
		System.out.println(dog.makeNoise()); // phew! cause dogs meow.
	}
}
---
May 19 2018
parent reply KingJoffrey <KingJoffrey KingJoffrey.com> writes:
On Saturday, 19 May 2018 at 08:32:28 UTC, Uknown wrote:

 I ported your example to Java. Surprisingly, it compiled and 
 executed just fine:


All I see, is a class, with static members. How else would it 
work?

This is the equivalent of my D example, in Java:

( it won't even compile.  phew!  )

--------------
public class test
{
     public static void main(String[] args)
     {
         Dog dog = new Dog();
         dog.noiseType = "meow";              // no way jose
         System.out.println(dog.makeNoise()); // phew! cause dogs 
don't meow.
     }
}

class Dog
{
     private String noiseType = "woof";

     public String makeNoise()
     {
         return this.noiseType;
     }
}
--------------------
May 19 2018
parent reply Uknown <sireeshkodali1 gmail.com> writes:
On Saturday, 19 May 2018 at 09:10:32 UTC, KingJoffrey wrote:

 On Saturday, 19 May 2018 at 08:32:28 UTC, Uknown wrote:

 I ported your example to Java. Surprisingly, it compiled and 
 executed just fine:


 All I see, is a class, with static members. How else would it 
 work?

 This is the equivalent of my D example, in Java:

 ( it won't even compile.  phew!  )


The point was encapsulation as you defined it was broken. private 
members were directly modified outside their class. In your 
words, everyone was a friend.
May 19 2018
parent reply KingJoffrey <KingJoffrey KingJoffrey.com> writes:
On Saturday, 19 May 2018 at 09:37:56 UTC, Uknown wrote:

 The point was encapsulation as you defined it was broken. 
 private members were directly modified outside their class. In 
 your words, everyone was a friend.


This is why we have coding standards ;-)

https://www.nccgroup.trust/globalassets/our-research/us/whitepapers/2017/april/accessing-private-fields-outside-of-classes-in-java.pdf
May 19 2018
parent reply Neia Neutuladh <neia ikeran.org> writes:
On Saturday, 19 May 2018 at 09:49:39 UTC, KingJoffrey wrote:

 On Saturday, 19 May 2018 at 09:37:56 UTC, Uknown wrote:

 The point was encapsulation as you defined it was broken. 
 private members were directly modified outside their class. In 
 your words, everyone was a friend.


 This is why we have coding standards ;-)

 https://www.nccgroup.trust/globalassets/our-research/us/whitepapers/2017/april/accessing-private-fields-outside-of-classes-in-java.pdf


Coding standards are good enough for Java but not for D?
May 19 2018
parent KingJoffrey <KingJoffrey KingJoffrey.com> writes:
On Saturday, 19 May 2018 at 17:15:45 UTC, Neia Neutuladh wrote:

 On Saturday, 19 May 2018 at 09:49:39 UTC, KingJoffrey wrote:

 On Saturday, 19 May 2018 at 09:37:56 UTC, Uknown wrote:

 The point was encapsulation as you defined it was broken. 
 private members were directly modified outside their class. 
 In your words, everyone was a friend.


 This is why we have coding standards ;-)

 https://www.nccgroup.trust/globalassets/our-research/us/whitepapers/2017/april/accessing-private-fields-outside-of-classes-in-java.pdf


 Coding standards are good enough for Java but not for D?


Coding standards are required for any quality development.

How many in the D community have, let alone follow, coding 
standards when coding in D?

The problem with D, is that everything is essentially unsafe, by 
default.

To get safety, you have to implement a variety of coding 
standards, that are simply not required as much in other 
mainstream langauges. The worst for me, is that you have to 
implement 'a one class per module coding standard' (because 
otherwise your privates just suddenly morph into public), just to 
ensure the safety of your interface from human error. That's 
crazy!

In any case...development is moving towards safer langauges, and 
towards safer by default.

D has a lot to catch up with, cause other langauges are decades 
ahead here.

That's why I see D has this little boutique langauges, for 
programmers that just want to get away with doing whatever - by 
default.
May 19 2018
prev sibling next sibling parent Neia Neutuladh <neia ikeran.org> writes:
On Saturday, 19 May 2018 at 04:01:18 UTC, KingJoffrey wrote:

 Mmm.. that brings me back to the idea of sealed at the class 
 level again.

 class A
 {
    private int x;
    private(this) int y;  // imagine if you have lots of private 
 variables.
                          // this could become pretty anoying - 
 and kinda redundant.
 }


All attributes in D work the same way. You can write things like:

class A
{
    Jsonize:
   private:
   int a;
   string b;

   protected
   {
     long c;
   }

    safe:
   void privateSafeFunction() {}
   void otherPrivateSafeFunction() {}
}

Perhaps you should learn more about the language before proposing 
specific changes?
May 19 2018
prev sibling parent reply Gheorghe Gabriel <knoppy273 live.com> writes:
On Saturday, 19 May 2018 at 04:01:18 UTC, KingJoffrey wrote:

 On Friday, 18 May 2018 at 16:24:24 UTC, Gheorghe Gabriel wrote:

 On Friday, 18 May 2018 at 15:57:06 UTC, bachmeier wrote:

 On Friday, 18 May 2018 at 15:40:52 UTC, KingJo

 class A {
    private int x;
    private(this) int y;
 }


 I agree that this looks a bit strange.
 My initial proposal was "sealed" instead "private(this)" today.


 Mmm.. that brings me back to the idea of sealed at the class 
 level again.

 class A



 {
    private int x;
    private(this) int y;  // imagine if you have lots of private 
 variables.
                          // this could become pretty anoying - 
 and kinda redundant.
 }

 class A
 {
    private int x;
    sealed int y; // again, what if you have lots of private 
 variables that
                  // that you really want sealed.
 }


 // Now. Back to the idea of sealed.
 // abosolute consistency of your private variables.
 // no redundancy.
 // no some 'private', some 'sealed' confusion.
 // no some 'private' (but really public) some 'private(this) .. 
 confusion.
 //
 sealed class A{
     private int x;
     private int y;
 }

 downside, is adding a new keyword, and getting agreement on 
 what that new keyword should be.

 So I've come full circle again, and believe my idea is worth 
 further consideration.


If you have
sealed class A {
    private {
        // members
    }
}
Then you can't use the defualt 'private' if you need it for a 
specific member.

But if sealed is an access type of a member, 99% you will use 
sealed insted private in a class, so it is not redundant.

class A {
    sealed {
        // members
    }
    private int friendMember;
}

And you use private keyword only if you need to access that 
variable from a class/function/struct.. in the same module, like 
a friend.
May 19 2018
parent reply KingJoffrey <KingJoffrey KingJoffrey.com> writes:
On Saturday, 19 May 2018 at 17:38:48 UTC, Gheorghe Gabriel wrote:

 If you have
 sealed class A {
    private {
        // members
    }
 }
 Then you can't use the defualt 'private' if you need it for a 
 specific member.

 But if sealed is an access type of a member, 99% you will use 
 sealed insted private in a class, so it is not redundant.

 class A {
    sealed {
        // members
    }
    private int friendMember;
 }

 And you use private keyword only if you need to access that 
 variable from a class/function/struct.. in the same module, 
 like a friend.


I agree. But then we end up with what D should have implemented 
in the first place - C++ friends ;-)

(and in fact, quality software development should rarely, if 
ever, require the use of friend (which is just a managed way of 
breaking encapsulation - but, its managed, and managed by the 
programmer explicitly).

But in D, everything is your friend - you don't get to manage 
anything - which even to the dumbest of us, must suggest some 
impact on the quality of the software that will get developed in 
D. So, now, we need to consider absurd coding standards to get 
around this facebook style friendship problem (like implementing 
the proposed 'one class per module' crap - and btw. that is the 
purest form of OOP - so D actually forces you into this purest 
form of OOP - even other mainstream OOP langauges don't force 
that on you).

There is absolutely no reason why D cannot have both (the current 
way D does it, and the C++ way). It's obviously technically 
possible. It's obvious it would attract a great deal more 
programmers to D. It doesn't really complicate the language at 
all - that's just an excuse not to change. And, it's obvious, 
that protecting the interface would result in better quality 
software. It's a core fundamental principle of quality software.

It's just a matter of getting more diverse people into the D 
'community'.

But I get the feeling that's not what most D people want. The 
status quo is pretty comfortable for many, it seems.

Maybe in decade time, if/when D v3 comes out. But I won't be 
holding my breath.
May 19 2018
parent reply Dave Jones <dave jones.com> writes:
On Sunday, 20 May 2018 at 02:45:25 UTC, KingJoffrey wrote:

 On Saturday, 19 May 2018 at 17:38:48 UTC, Gheorghe Gabriel 
 wrote:

 But in D, everything is your friend - you don't get to manage


You want to be taken seriously and yet you repeat false 
statements over and over again.



 There is absolutely no reason why D cannot have both (the 
 current way D does it, and the C++ way). It's obviously 
 technically possible.


Being technically possible or even easy to implement is not an 
argument for including something.



 It's obvious it would attract a great deal more programmers to 
 D.


Pure conjecture. You don't know why people choose not to use D, 
you know why you choose not to use it. Assuming your opinion is 
shared by all these supposed people is at best naive at worst an 
indication of narcissism.

I'll assume for now that you are young, idealistic and naive.



 It doesn't really complicate the language at all - that's just 
 an excuse not to change. And, it's obvious, that protecting the 
 interface would result in better quality software. It's a core 
 fundamental principle of quality software.

 It's just a matter of getting more diverse people into the D 
 'community'.


Yes because if a group of people don't accept your argument about 
something obviously there is something wrong with them.

OK it's starting to look more like narcissism.



 But I get the feeling that's not what most D people want. The 
 status quo is pretty comfortable for many, it seems.


No shit... you're just getting that feeling now? You remind me of 
my teenage son, it takes about 100 times of telling him something 
before it sticks in his head.

Let me ask you this...

How do you get comfortable with something? By using it, trying 
it, and finding that it works. You don't get comfortable with 
having a stone in your shoe, so if this feature was the nightmare 
you say it is all these people using D wouldn't be OK with it.

But again it's utterly pointless because you cannot grasp that. 
You are unable to even consider that something "other" might 
work. You are a zealot in that respect, that's why you 
exaggerate, misrepresent the other side of the argument, predict 
doom for the heathens, and never budge on your position.

Anyway... feel free to misrepresent what I've said, engage in 
hyperbole, snip the parts you cant argue with, speak for all the 
people who chose not to use D, tell D it's doomed if they don't 
do what you say, it'll never be popular, that it's all idiotic. 
Etc...
May 20 2018
parent reply KingJoffrey <KingJoffrey KingJoffrey.com> writes:
On Sunday, 20 May 2018 at 11:19:01 UTC, Dave Jones wrote:

 On Sunday, 20 May 2018 at 02:45:25 UTC, KingJoffrey wrote:

 On Saturday, 19 May 2018 at 17:38:48 UTC, Gheorghe Gabriel 
 wrote:

 But in D, everything is your friend - you don't get to manage


 You want to be taken seriously and yet you repeat false 
 statements over and over again.



 There is absolutely no reason why D cannot have both (the 
 current way D does it, and the C++ way). It's obviously 
 technically possible.


 Being technically possible or even easy to implement is not an 
 argument for including something.



 It's obvious it would attract a great deal more programmers to 
 D.


 Pure conjecture. You don't know why people choose not to use D, 
 you know why you choose not to use it. Assuming your opinion is 
 shared by all these supposed people is at best naive at worst 
 an indication of narcissism.

 I'll assume for now that you are young, idealistic and naive.



 It doesn't really complicate the language at all - that's just 
 an excuse not to change. And, it's obvious, that protecting 
 the interface would result in better quality software. It's a 
 core fundamental principle of quality software.

 It's just a matter of getting more diverse people into the D 
 'community'.


 Yes because if a group of people don't accept your argument 
 about something obviously there is something wrong with them.

 OK it's starting to look more like narcissism.



 But I get the feeling that's not what most D people want. The 
 status quo is pretty comfortable for many, it seems.


 No shit... you're just getting that feeling now? You remind me 
 of my teenage son, it takes about 100 times of telling him 
 something before it sticks in his head.

 Let me ask you this...

 How do you get comfortable with something? By using it, trying 
 it, and finding that it works. You don't get comfortable with 
 having a stone in your shoe, so if this feature was the 
 nightmare you say it is all these people using D wouldn't be OK 
 with it.

 But again it's utterly pointless because you cannot grasp that. 
 You are unable to even consider that something "other" might 
 work. You are a zealot in that respect, that's why you 
 exaggerate, misrepresent the other side of the argument, 
 predict doom for the heathens, and never budge on your position.

 Anyway... feel free to misrepresent what I've said, engage in 
 hyperbole, snip the parts you cant argue with, speak for all 
 the people who chose not to use D, tell D it's doomed if they 
 don't do what you say, it'll never be popular, that it's all 
 idiotic. Etc...


Come on Dave.

18+ years, and still less than 1000 programmers.

As I've said, I can have more that one class in a file in a 
variety of different mainstream languages, which represent about 
20 million developers, and still have the compiler protect that 
interface from abuse, including accidental misuse.

You cannot get this in D, and yet 20 million developers have had 
this for decades.

When they come over to D, their' told, stuff you, we don't do it 
that way in D, and btw, we don't care about your ideas on how we 
could easily get D to do it both ways. We prefer our own way, so 
you get stuffed.

That's kind of what I've hearing from the D community.

Of course, that kind of attitude can only invite the same 
attitude back to the D community.

Let's hope you truly don't represent the D community, cause then 
my comments are not hyperbole, they are fact.
May 20 2018
next sibling parent reply Dave Jones <dave jones.com> writes:
On Monday, 21 May 2018 at 03:19:34 UTC, KingJoffrey wrote:

 On Sunday, 20 May 2018 at 11:19:01 UTC, Dave Jones wrote:

 On Sunday, 20 May 2018 at 02:45:25 UTC, KingJoffrey wrote:

 On Saturday, 19 May 2018 at 17:38:48 UTC, Gheorghe Gabriel 
 wrote:


 Anyway... feel free to misrepresent what I've said, engage in 
 hyperbole, snip the parts you cant argue with, speak for all 
 the people who chose not to use D, tell D it's doomed if they 
 don't do what you say, it'll never be popular, that it's all 
 idiotic. Etc...


 Come on Dave.

 18+ years, and still less than 1000 programmers.


Do you have a citation for that? I have no idea how many users 
there are tbh.



 As I've said, I can have more that one class in a file in a 
 variety of different mainstream languages, which represent 
 about 20 million developers, and still have the compiler 
 protect that interface from abuse, including accidental misuse.


Delphi had the exact same thing and was probably the second 
largest IDE/Development platform on Windows for a very long time. 
The idea that it is a make or break feature is a figment of your 
imagination.



 You cannot get this in D, and yet 20 million developers have 
 had this for decades.


20 million developers have had the friend feature for decades, it 
didn't stop Java becoming huge without it.

The point is you constantly make logical fallacies of that 
sort... A has feature B and A is popular so it follows that to be 
popular you must implement B.

And if I was taking your tone and attitude in pointing this out I 
would call that idiotic and by implication would be calling you 
an idiot. I'm not by the way, I'm being mature for once :) and 
just pointing it out without labelling you.



 When they come over to D, their' told, stuff you, we don't do 
 it that way in D, and btw, we don't care about your ideas on 
 how we could easily get D to do it both ways. We prefer our own 
 way, so you get stuffed.


Many people have engaged with you on your ideas. But lets be 
honest why should they care about your ideas when you clearly 
dont care about what they are saying? You have your position that 
"private means private" and that is the end of it. Nothing anyone 
can say will change your mind about that. That's why it's 
pointless, why talking to you is pointless.

And you quickly resort to being derogatory when you dont get your 
own way, for example "LOL less than 1000 users after 15 years". 
Stuff like that. And you want to be taken seriously?

BTW this is a user newsgroup it's not the steering group or the 
boardroom. Why on earth would you think you can change the 
direction of the language by shouting loudly in the local boozer?



 That's kind of what I've hearing from the D community.


People pointing out flaws in your argument, saying this is what 
you have to do to get your ideas accepted and these are the kind 
of issues you will have to overcome, is not telling you to get 
stuffed.

The problem is you dont seem to handle people disagreeing with 
you very well, you take it personally, that's why you resort to 
hyperbole and misrepresenting their position. You react 
emotionally instead of calm honest assessment of the facts.

If people say "but D works for me, I like this feature" you say 
it's idiotic and a sign of small language mentality.



 Of course, that kind of attitude can only invite the same 
 attitude back to the D community.


Go back and read over both threads, people weren't rude to you. 
They basically said "huh works for me" and "takes a lot to get a 
change accepted".



 Let's hope you truly don't represent the D community, cause 
 then my comments are not hyperbole, they are fact.


I have very little to do with anything here tbh, i just tinker in 
D, dont have time for much more than that.
May 21 2018
parent reply KingJoffrey <KingJoffrey KingJoffrey.com> writes:
On Monday, 21 May 2018 at 09:16:42 UTC, Dave Jones wrote:

 da dah dah....
 da dah dah dahh  da d ....
 ..
 .....
 ... da dah..
 ..da..
 da ...da....dada.........da...da........da.........


Thanks Dave.

Your contributions to the discussion have been really insightful, 
and most valuable.

I'm sure we can all learn from your great wisdom.

Now, for the benefit of those who haven't followed these 
discussions, so that you too can benefit from Dave's keen 
insight, I'll sum up Daves' stupendous contribution like this:

"Ours is not to reason why; Ours is but to do or die,"

Thanks again Dave.
May 21 2018
next sibling parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Monday, 21 May 2018 at 09:56:22 UTC, KingJoffrey wrote:

 On Monday, 21 May 2018 at 09:16:42 UTC, Dave Jones wrote:

 da dah dah....
 da dah dah dahh  da d ....
 ..
 .....
 ... da dah..
 ..da..
 da ...da....dada.........da...da........da.........


 Thanks Dave.

 Your contributions to the discussion have been really 
 insightful, and most valuable.

 I'm sure we can all learn from your great wisdom.

 Now, for the benefit of those who haven't followed these 
 discussions, so that you too can benefit from Dave's keen 
 insight, I'll sum up Daves' stupendous contribution like this:

 "Ours is not to reason why; Ours is but to do or die,"

 Thanks again Dave.


If you resort to mockery, then that means you have lost the 
argument.
May 21 2018
parent KingJoffrey <KingJoffrey KingJoffrey.com> writes:
On Monday, 21 May 2018 at 13:36:32 UTC, 12345swordy wrote:

 If you resort to mockery, then that means you have lost the 
 argument.


I prefer to think of it as sarcasm, not mockery.

Sarcasm is a form of intelligent expression, to wield however you 
see fit
(not unlike a module in D ;-)

For me, sarcasm is the ultimate weapon, against stupidity.

Don't confuse sarcasm with mockery.

Mockery involves hostility, and is a tool the weak use, to bully 
others.
May 21 2018
prev sibling parent Dave Jones <dave jones.com> writes:
On Monday, 21 May 2018 at 09:56:22 UTC, KingJoffrey wrote:

 On Monday, 21 May 2018 at 09:16:42 UTC, Dave Jones wrote:

 da dah dah....
 da dah dah dahh  da d ....
 ..
 .....
 ... da dah..
 ..da..
 da ...da....dada.........da...da........da.........


 Thanks Dave.

 Your contributions to the discussion have been really 
 insightful, and most valuable.

 I'm sure we can all learn from your great wisdom.

 Now, for the benefit of those who haven't followed these 
 discussions, so that you too can benefit from Dave's keen 
 insight, I'll sum up Daves' stupendous contribution like this:

 "Ours is not to reason why; Ours is but to do or die,"

 Thanks again Dave.


And yet again when he cant argue the point he sticks his fingers 
in his ears and starts shouting "la la la I cant hear you" like a 
spoilt little child.

Well done Joffers.
May 21 2018
prev sibling parent reply bauss <jj_1337 live.dk> writes:
On Monday, 21 May 2018 at 03:19:34 UTC, KingJoffrey wrote:

 18+ years, and still less than 1000 programmers.


What kind of misinformation is that?

vibe.d alone has over 2000 downloads per week and I'll mind you 
that regular users of vibe.d does not download or update the 
package that often.

That means a large percentage of those are either new people 
trying out vibe.d.

And most people programming in D do not even do web related 
programming or uses vibe.d, so in that sense the amount of people 
using D is WAY MORE than the amount of people weekly using vibe.d.

Put that into perspective.

I cannot take you seriously when all you do is spread 
misinformation and invalid statistics.
May 22 2018
parent Sir Ronald Fisher <ronny stat.com> writes:
On Tuesday, 22 May 2018 at 07:34:24 UTC, bauss wrote:

 I cannot take you seriously when all you do is spread 
 misinformation and invalid statistics.


Don't under-estimate, the power of misinformation and invalid 
statistics.

After all, if both can help you become supreme leader of the 
worlds foremost superpower, then, maybe they can also convince 
people to make 'the class' a protected species, and save it from 
extinction.
May 22 2018
prev sibling parent KingJoffrey <KingJoffrey KingJoffrey.com> writes:
On Friday, 18 May 2018 at 16:24:24 UTC, Gheorghe Gabriel wrote:

 On Friday, 18 May 2018 at 15:57:06 UTC, bachmeier wrote:

 On Friday, 18 May 2018 at 15:40:52 UTC, KingJo

 class A {
    private int x;
    private(this) int y;
 }


 I agree that this looks a bit strange.
 My initial proposal was "sealed" instead "private(this)" today.


I'm really struggling to come up with any acceptable use case, 
whereby my class would want to have both private and sealed 
variables.( whether the word sealed is used, or private(this) is 
used, is irrelevant to this point though).

Can anyone come up with use case for this code below?

(It may well encourage even poorer software engineering, that 
private morhping into public).

-----
class A
{
    private int x; // ok, really public within the module.
    sealed int y; // now really private within the module.
}
----
May 18 2018
prev sibling parent reply Sjoerd Nijboer <sjoerdnijboer gmail.com> writes:
On Friday, 18 May 2018 at 15:57:06 UTC, bachmeier wrote:

 class A {
    private int x;
    private(this) int y;
 }


Instead of such a syntax if this ever comes to be, we could just 
introduce a new keyword into the language.

class A {
    private int x;
    closed int y; //closed for acces outside this class.
    owned int z; //owned by this class.
    inside int zz; //only accessible inside this class.
}

As far as I can tell we don't need a `private(this)` or 
`private(classname)` declaration. I'd much rather have a keyword 
specifically designed for the thing that it does.

D is at the point that there's already legacy code so you can't 
use the `private` keyword anymore whitout doing something funky 
with defining it private to class scope any other given scope. It 
would also raise the question of "Why can't I have 
`private(functionName)`? Does that make sense?"

I do see how this could be usefull if you had a 6000 line static 
function that you don't want to have access to a private member 
that is defined in thesame module. But then again, one could 
simply extract it to its own module, reference the former module 
and use those classes.

I personally find having no class private members incredibly 
usefull since I can use them for unittests that way.
Then I can enforce the existance of a class member regardless of 
its scope to exist and therefore enforce the use of a given 
approach to the problem a class is solving.
While you might say that a unittest shouldn't acces private 
members and only public members, there are plenty of testcases 
where one would want to write a unittest to set a given variable 
via public function and then test if the appropriate private 
fields are properly set. While this sounds like a trivial usecase 
I believe it to be a verry big one in practice since it removes a 
lot of boilerplate code from your unit-tests, together with 
exposing the innards of a class's implementation to the outside 
world just so you can unit-test it. The last point is something I 

think D has (accidentally) solved this in a beautiful way, and I 
would dislike to see this feature go.
May 21 2018
parent reply KingJoffrey <KingJoffrey KingJoffrey.com> writes:
On Monday, 21 May 2018 at 13:39:12 UTC, Sjoerd Nijboer wrote:

 While you might say that a unittest shouldn't acces private 
 members and only public members, there are plenty of testcases 
 where one would want to write a unittest to set a given 
 variable via public function and then test if the appropriate 
 private fields are properly set. While this sounds like a 
 trivial usecase I believe it to be a verry big one in practice 
 since it removes a lot of boilerplate code from your 
 unit-tests, together with exposing the innards of a class's 
 implementation to the outside world just so you can unit-test 
 it.


I have to ask, why isn't that unittest your talking about, within 
the scope of the class? Why is it outside the class, testing 
private innards of the class?

I have trouble getting my head around this.


 The last point is something I don't like about OOP + TDD in 

 solved this in a beautiful way, and I would dislike to see this 
 feature go.


I'm not sure I understand this. You mean you don't like 'private'?

You think an object doesn't have a right, to privacy?

Are you one of those facebook employees?

And who suggested getting rid of anything?
May 21 2018
parent reply Sjoerd Nijboer <sjoerdnijboer gmail.com> writes:
On Monday, 21 May 2018 at 14:30:21 UTC, KingJoffrey wrote:

 On Monday, 21 May 2018 at 13:39:12 UTC, Sjoerd Nijboer wrote:

 While you might say that a unittest shouldn't acces private 
 members and only public members, there are plenty of testcases 
 where one would want to write a unittest to set a given 
 variable via public function and then test if the appropriate 
 private fields are properly set. While this sounds like a 
 trivial usecase I believe it to be a verry big one in practice 
 since it removes a lot of boilerplate code from your 
 unit-tests, together with exposing the innards of a class's 
 implementation to the outside world just so you can unit-test 
 it.


 I have to ask, why isn't that unittest your talking about, 
 within the scope of the class? Why is it outside the class, 
 testing private innards of the class?

 I have trouble getting my head around this.


This hypotetical unittest is testing a hypotetical class in a 
hypotetical module with hypotetical properties.
Why is it outside the class? I don't know, maybe it needs access 
to two classes which are defined in thesame module. But also out 
of personal preference, I don't like random unittest declarations 
inside my class. Regardless, I think it's important for unittests 
to be able to do this.


 The last point is something I don't like about OOP + TDD in 

 solved this in a beautiful way, and I would dislike to see 
 this feature go.


 I'm not sure I understand this. You mean you don't like 
 'private'?

 You think an object doesn't have a right, to privacy?

 Are you one of those facebook employees?

 And who suggested getting rid of anything?


Nope, I'm simply a bystander who sees lack of class scope as a 
"feature" of D that is usefull in some cases while not hurting 
idiomatic OOP as long as you only define a single class (+ 
unittests) inside a module.
If you want that too but still want static functions outside 

Which is why I don't see any reason to add this.

But besides that, I just wanted to put forward that we don't need 
to do `private(this)` or `private(className)` if this ever became 
a language feature because it would be confusing as to why it 
could bind to class or struct scope but not to any other scope 
and might as well introduce a new keyword which isn't regularly 
used in other languages like `sealed` but could instead come up 
with a new one.
I felt that my response was incomplete whitout adding I think 
that the concept of a class private in D would not be a good idea.

Also, I would verry much much like it if you would not resort to 
comparing me to "one of those facebook employees." It's just 
setting a mood for the conversation which no one likes, 
regardless what anyone thinks about facebook employees.
May 21 2018
next sibling parent reply KingJoffrey <KingJoffrey KingJoffrey.com> writes:
On Monday, 21 May 2018 at 14:46:40 UTC, Sjoerd Nijboer wrote:

 Also, I would verry much much like it if you would not resort 
 to comparing me to "one of those facebook employees." It's just 
 setting a mood for the conversation which no one likes, 
 regardless what anyone thinks about facebook employees.


people are so touchy here....

what's happended to the world...it's all going crazy...like some 
ideology is taking over peoples minds.... I don't get it...

you just can't say anything anymore, with offending someone... 
it's just ridiculous!

personally, I see it as a new form of bullying -- social bullying 
I'll call it.

And I really, really, really... don't like bullies!
May 21 2018
parent reply Dave Jones <dave jones.com> writes:
On Monday, 21 May 2018 at 14:54:57 UTC, KingJoffrey wrote:

 On Monday, 21 May 2018 at 14:46:40 UTC, Sjoerd Nijboer wrote:

 Also, I would verry much much like it if you would not resort 
 to comparing me to "one of those facebook employees." It's 
 just setting a mood for the conversation which no one likes, 
 regardless what anyone thinks about facebook employees.


 people are so touchy here....


You want to have your cake and eat it, you want to be immature 
and label and denigrate people but you also want to be taken 
seriously.

But you're too far up your own class to see it.
May 21 2018
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
Please stop replying Dave, it isn't worth it.

Do something more productive with your time :)
May 21 2018
parent Dave Jones <dave jones.com> writes:
On Monday, 21 May 2018 at 16:35:57 UTC, rikki cattermole wrote:

 Please stop replying Dave, it isn't worth it.

 Do something more productive with your time :)


I know, but... it helps me relax. ;-)
May 21 2018
prev sibling next sibling parent reply KingJoffrey <KingJoffrey KingJoffrey.com> writes:
On Monday, 21 May 2018 at 14:46:40 UTC, Sjoerd Nijboer wrote:

 Nope, I'm simply a bystander who sees lack of class scope as a 
 "feature" of D that is usefull in some cases while not hurting 
 idiomatic OOP as long as you only define a single class (+ 
 unittests) inside a module.
 If you want that too but still want static functions outside 

 Which is why I don't see any reason to add this.


And there's the point I'm trying to make.


private private, they have to resort to this. It makes no sense. 


Same for Java programmers, same for C++ programmers 
(class-oriented ones).

As it is, D tells them, stuff you, private is now 
private-but-module-public, and you have no say it.

My suggestions are about resolving this, in order to attract more 
programmers to D, because I doubt I'm the only person in the 
world, that believes an object has a right to privacy.

But as I've said, I do really get the feeling the D community 
does not want more programmers, unless they are like them.
May 21 2018
parent reply Gheorghe Gabriel <knoppy273 live.com> writes:
On Monday, 21 May 2018 at 15:07:39 UTC, KingJoffrey wrote:

 My suggestions are about resolving this, in order to attract 
 more programmers to D, because I doubt I'm the only person in 
 the world, that believes an object has a right to privacy.


Of course you are not the only person that believes that.
To have full private access in module scope is like you live in a 
building and there are no walls between apartments.
May 21 2018
parent 12345swordy <alexanderheistermann gmail.com> writes:
On Monday, 21 May 2018 at 15:30:40 UTC, Gheorghe Gabriel wrote:

 On Monday, 21 May 2018 at 15:07:39 UTC, KingJoffrey wrote:

 My suggestions are about resolving this, in order to attract 
 more programmers to D, because I doubt I'm the only person in 
 the world, that believes an object has a right to privacy.


 Of course you are not the only person that believes that.
 To have full private access in module scope is like you live in 
 a building and there are no walls between apartments.


If you put multiple classes in a single module, yeah it feels 
like it, that why people here recommend one class per module.
May 21 2018
prev sibling parent KingJoffrey <KingJoffrey KingJoffrey.com> writes:
On Monday, 21 May 2018 at 14:46:40 UTC, Sjoerd Nijboer wrote:

 This hypotetical unittest is testing a hypotetical class in a 
 hypotetical module with hypotetical properties.
 Why is it outside the class? I don't know, maybe it needs 
 access to two classes which are defined in thesame module. But 
 also out of personal preference, I don't like random unittest 
 declarations inside my class. Regardless, I think it's 
 important for unittests to be able to do this.


Fair enough. That is a reasonable position, I guess.

OK. So let's say, that the class-oriented programmer is now 
required to use one-class-per-module in D (in order to ensure the 
encaspulated private parts of the object are not penetrated by 
its neigbours in the module) - i.e the solution that most here 
seem to be suggesting.

Now, lets say that programmers wants to put in a unittest, in the 
same module (but outside the class - as you've suggested).

Let's also say, the programmer does *not* want the unittest to be 
able to penetrate the private parts of the class.

If human error creeps in to their unittest, as it inevitably 
will, then they will not know about this until runtime. How do 
they get around this problem? I guess, they'll be forced to put 
the unittest inside the class. But what if, like you, they don't 
want to?

Something like this below, would actually enhance the value of 
unittests too, because now the compiler would require your 
unittest to use the objects public interface (human error cannot 
creep in now - and people like me won't have to inspect every 
unittest to see that its programming to the interface):

---------------------
module test;

 safeinterface class Dog
{
     private string noiseType;

     public string makeNoise()
     {
         this.noiseType = "woof";
         return this.noiseType;
     }
}

unittest
{
     Dog d = new Dog();
     d.noiseType = "meow"; // ohhps. human error - lucky I used 
 safeinterface
                           // compiler will statically enforce 
this.
}
--------------
May 22 2018
prev sibling next sibling parent reply Gheorghe Gabriel <knoppy273 live.com> writes:
On Friday, 18 May 2018 at 15:40:52 UTC, KingJoffrey wrote:

 On Friday, 18 May 2018 at 14:32:33 UTC, bachmeier wrote:

 [...]


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



 [...]


 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.


Sometimes, I really need to put 2-3 or more different classes in 
a module and I don't want them to share private members (friend 
classes). The current solution is to create an individual module 
for each class, but I don't like it when my class logic-strucrure 
fits better in the same module. A better solution could be 
private(this). I am sure that D really needs something like this. 
I have been talking with my friend programmers for 4 hours and 
they don't like the fact that D classes couldn't protect thier
May 18 2018
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 5/18/18 12:07 PM, Gheorghe Gabriel wrote:


 Sometimes, I really need to put 2-3 or more different classes in a 
 module and I don't want them to share private members (friend classes). 
 The current solution is to create an individual module for each class, 
 but I don't like it when my class logic-strucrure fits better in the 
 same module. A better solution could be private(this). I am sure that D 
 really needs something like this. I have been talking with my friend 
 programmers for 4 hours and they don't like the fact that D classes 
 couldn't protect thier members in the same module. So they stuck on java 



You can "simulate" this by putting the classes into their own submodules 
of the same package.

I.e. you want:

module mod;

class C {

  private int _x;
  int x() { return _x; }

}

void foo(C c)
{
    auto x = c._x; // Oops, this should be an error
}

You can do this via:

mod/priv.d:
module mod.priv; // name however you like

class C { ... }

mod/package.d:
module mod;
public import mod.priv; // name isn't really important here

void foo(C c)
{
    auto x = c._x; // Truly an error
}

user.d:

import mod; // imports both foo and C as if they were both in the same 
module

-Steve
May 18 2018
parent KingJoffrey <KingJoffrey KingJoffrey.com> writes:
On Friday, 18 May 2018 at 17:28:59 UTC, Steven Schveighoffer 
wrote:

 You can "simulate" this by putting the classes into their own 
 submodules of the same package.


That just another hack to get around the problem.

It's not a solution to removing the problem, from being a problem.

(yeah, I know, not everyone thinks it's a problem.. been there 
done that).

private(this) is a lot easier, than being told you need to 
redesign your whole class layout to accomodate D's 'private is 
really public' concept.

Lets get rid of the problem (that prevents many from using D in 
the first place), rather that constatnly come up with new ways of 
telling them find a way around it.

btw. I only know of two reasons why private is public so far 
(from discussions).

1 - Voldemort types (don't know what it is, and don't care).

2 - unittests (but, if the unit tests, testing your class, are 
outside your class accessing it's private parts, then I have 
trouble considering them to be unittests at all.
May 18 2018
prev sibling parent reply Dave Jones <dave jones.com> writes:
On Friday, 18 May 2018 at 15:40:52 UTC, KingJoffrey wrote:

 On Friday, 18 May 2018 at 14:32:33 UTC, bachmeier wrote:


 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.


"Ohh Arya you will never be a lady if you keep walking around in 
your underclothes, even if it is just inside our chambers. You'll 
never have any friends or be popular, no one will ask you to the 
ball. You'll never be a lady."

Ohh the drama...



 May 18 2018



  parent reply Chris M. <chrismohrfeld comcast.net>  writes:


On Friday, 18 May 2018 at 17:59:04 UTC, Dave Jones wrote:

 On Friday, 18 May 2018 at 15:40:52 UTC, KingJoffrey wrote:

 On Friday, 18 May 2018 at 14:32:33 UTC, bachmeier wrote:


 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.


 "Ohh Arya you will never be a lady if you keep walking around 
 in your underclothes, even if it is just inside our chambers. 
 You'll never have any friends or be popular, no one will ask 
 you to the ball. You'll never be a lady."

 Ohh the drama...


Let's just stop this part of the convo since it's clearly not 
going to bring us anywhere



 May 18 2018



  parent reply Dave Jones <dave jones.com>  writes:


On Friday, 18 May 2018 at 18:12:55 UTC, Chris M. wrote:

 On Friday, 18 May 2018 at 17:59:04 UTC, Dave Jones wrote:

 On Friday, 18 May 2018 at 15:40:52 UTC, KingJoffrey wrote:

 On Friday, 18 May 2018 at 14:32:33 UTC, bachmeier wrote:


 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.


 "Ohh Arya you will never be a lady if you keep walking around 
 in your underclothes, even if it is just inside our chambers. 
 You'll never have any friends or be popular, no one will ask 
 you to the ball. You'll never be a lady."

 Ohh the drama...


 Let's just stop this part of the convo since it's clearly not 
 going to bring us anywhere


So lets stop the pointless gentle mockery and concentrate solely 
on the pointless.

Sounds like a plan!



 May 18 2018



 next sibling parent reply Maurice Huuskes <mahuuskes runic.eu>  writes:


On Friday, 18 May 2018 at 20:30:21 UTC, Dave Jones wrote:

 On Friday, 18 May 2018 at 18:12:55 UTC, Chris M. wrote:

 On Friday, 18 May 2018 at 17:59:04 UTC, Dave Jones wrote:

 On Friday, 18 May 2018 at 15:40:52 UTC, KingJoffrey wrote:

 On Friday, 18 May 2018 at 14:32:33 UTC, bachmeier wrote:


 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.


 "Ohh Arya you will never be a lady if you keep walking around 
 in your underclothes, even if it is just inside our chambers. 
 You'll never have any friends or be popular, no one will ask 
 you to the ball. You'll never be a lady."

 Ohh the drama...


 Let's just stop this part of the convo since it's clearly not 
 going to bring us anywhere


 So lets stop the pointless gentle mockery and concentrate 
 solely on the pointless.

 Sounds like a plan!


The only thing that's going to drive this discussion forward is a 
few example use-cases (potentially borrowed from other languages 
that ran into similar 'problems'). I am new to D myself and how 
private works did surprise me but using the module/package method 
seems elegant enough to me.



 May 18 2018



  parent  KingJoffrey <KingJoffrey KingJoffrey.com>  writes:


On Friday, 18 May 2018 at 22:10:51 UTC, Maurice Huuskes wrote:

 The only thing that's going to drive this discussion forward is 
 a few example use-cases (potentially borrowed from other 
 languages that ran into similar 'problems'). I am new to D 
 myself and how private works did surprise me but using the 
 module/package method seems elegant enough to me.


I'll be honest. If people in the D community need to be provided 
with 'use cases' whereby private should not morph in public, then 
ya' all have bigger problems than you realise ;-)

should immutable morph into mutable?
(cause that might be convenient on rare occasions)

should const just morph in non-constant
(cause that might be convenient on rare occasions)

should safe morph into unsafe
(cause that might be convenient on rare occasions)

so why should private morph into public?
(oh.. i know...cause that might be convenient on rare occasions)

it's a really odd design decision to relax that rule just for 
'private', and, it can have a really big impact on software 
quality (not to mention security).

it means, now you have to 'extra care'. cause the compiler won't 
tell you that you accidently accessed the private part - you'll 
have to work that out during your debugging sessions.

or, it means you have to find some hack to get around it.. (one 
class per module).

the option to stop private morphing into public, and the option 
to have compile time check of your semantics, is what the vast 
majority of programmers in the world already enjoy. Come on D. 
get with it!

But in any case, ya' all decided - cause D has no place in my 
development team until I can have more than one class in a 
module, and not be told that my private parts have to be public.

I believe this will continue to hold back D - until it empowers 
the programmer to have that control.



 May 18 2018



prev sibling  parent  KingJoffrey <KingJoffrey KingJoffrey.com>  writes:


On Friday, 18 May 2018 at 20:30:21 UTC, Dave Jones wrote:

 So lets stop the pointless gentle mockery and concentrate 
 solely on the pointless.

 Sounds like a plan!


you mean, follow your lead?  now there's a plan!

I like robust conversations too ;-)

But some semblance on sanity, in that robustness, would also be 
useful.



 May 18 2018



prev sibling next sibling parent reply Mike Parker <aldacron gmail.com>  writes:


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.



 May 18 2018



 next sibling parent reply KingJoffrey <KingJoffrey KingJoffrey.com>  writes:


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)



 May 18 2018



  parent  Mike Parker <aldacron gmail.com>  writes:


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?



 May 18 2018



prev sibling  parent  aliak <something something.com>  writes:


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



 May 18 2018



prev sibling  parent  Chris M. <chrismohrfeld comcast.net>  writes:


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



 May 18 2018



prev sibling  parent  KingJoffrey <KingJoffrey KingJoffrey.com>  writes:


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



 May 18 2018



prev sibling  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


Hi folks, it looks like at least a few branches of this thread have run 
well past their useful course and into tedious territory.

We don't like to go about killing threads, so we kindly ask that you all 
refrain from posting in this thread going forward.


Thanks much!

Andrei



 May 21 2018



 next sibling parent  VectorThis <VectorThis VectorThis.com>  writes:


On Monday, 21 May 2018 at 19:51:38 UTC, Andrei Alexandrescu wrote:

 Hi folks, it looks like at least a few branches of this thread 
 have run well past their useful course and into tedious 
 territory.

 We don't like to go about killing threads, so we kindly ask 
 that you all refrain from posting in this thread going forward.


 Thanks much!

 Andrei


wtf!

That's the whole reason Dave got involved in this discussion - to 
kill it off.

You've just empowered people like Dave.

Well done Andrei.



 May 21 2018



prev sibling  parent reply Bjarne Stroustrup <whatever wherever.com>  writes:


On Monday, 21 May 2018 at 19:51:38 UTC, Andrei Alexandrescu wrote:

 Hi folks, it looks like at least a few branches of this thread 
 have run well past their useful course and into tedious 
 territory.

 We don't like to go about killing threads, so we kindly ask 
 that you all refrain from posting in this thread going forward.


 Thanks much!

 Andrei


Andrei.

Any debate about restoring the rights and autonomy of the class, 
should not be killed off.

Any programming language that discriminates against the class, 
encourages class warfare, does not deserve to be called a 
programming langauge.

Let the debate continue....don't further disempower those 
advocating for the rights of the class.

Don't worry class, some of us will always stand up to those that 
wish to destroy you.

(ohh... is that what 'destroy' means... now I get it Andrei).



 May 21 2018



 next sibling parent  Grady Booch <gb gb.com>  writes:


On Tuesday, 22 May 2018 at 03:10:39 UTC, Bjarne Stroustrup wrote:

 Any debate about restoring the rights and autonomy of the 
 class, should not be killed off.

 Any programming language that discriminates against the class, 
 encourages class warfare, does not deserve to be called a 
 programming langauge.

 Let the debate continue....don't further disempower those 
 advocating for the rights of the class.

 Don't worry class, some of us will always stand up to those 
 that wish to destroy you.

 (ohh... is that what 'destroy' means... now I get it Andrei).


I agree with my close, long time friend, Bjarne.

Private access specifiers are used intentionally, in conjunction 
with carefully designed public method implementationsm, to 
enforce class invariants—constraints on the state of objects.

As langauges continue towards relaxing, and even 'destroying' 
these constraints, the class will become an extinct species.

And yet, the class/object model has proven to be a very powerful 
and unifying concept. If we destroy the class, we destroy the 
very core of not just the class, but also ourselves.

For that matter, if we destroy the interface of the function, we 
end up in the same disastrous situation. i.e pointers! god help 
us all, cause nobody else can!

Please, let's not destroy the autonomy of the object. We are 
ourselves, objects, afterall.



 May 21 2018



prev sibling  parent reply 12345swordy <alexanderheistermann gmail.com>  writes:


On Tuesday, 22 May 2018 at 03:10:39 UTC, Bjarne Stroustrup wrote:


 Any debate about restoring the rights and autonomy of the 
 class, should not be killed off.

 Any programming language that discriminates against the class, 
 encourages class warfare, does not deserve to be called a 
 programming langauge.


Knock it off with the hyperbole language already, this is a 
programming language not a civil rights movement.



 May 22 2018



  parent  Dave Jones <dave jones.com>  writes:


On Tuesday, 22 May 2018 at 13:33:12 UTC, 12345swordy wrote:

 On Tuesday, 22 May 2018 at 03:10:39 UTC, Bjarne Stroustrup 
 wrote:


 Any debate about restoring the rights and autonomy of the 
 class, should not be killed off.

 Any programming language that discriminates against the class, 
 encourages class warfare, does not deserve to be called a 
 programming langauge.


 Knock it off with the hyperbole language already, this is a 
 programming language not a civil rights movement.


The guy is unstable and has gone careening off since I kicked his 
soapbox... i mean his argument to pieces.



 May 22 2018