Re: WTF! new in class is static?!?!

[KingJoffrey via Digitalmars-d-learn]

On Sunday, 10 June 2018 at 01:27:50 UTC, bauss wrote:

On Saturday, 9 June 2018 at 12:40:07 UTC, RealProgrammer wrote:
maybe you and others in the D 'community' should start paying 
attention to the 'opinions' of those who do professional 
development with professional compilers.


I do professional work with a professional compiler aka. The D 
compiler and I've been doing so for years.


Well then, you should like my idea for the dconf '2019' logo...

Dman and a bug, holding hands, and the bug saying "I'm not a bug, 
I'm a feature!".

Re: WTF! new in class is static?!?!

[KingJoffrey via Digitalmars-d-learn]

On Saturday, 9 June 2018 at 12:56:55 UTC, rikki cattermole wrote:

But unlike you "king", Bauss isn't using tor to ban evade.


why you wanna ban little old me?

is it cause I made a crticism of D?

did i hurt your feelings?

..and everyone I know uses tor - and you should too - whether 
you're evading something or not - otherwise tor has no value - 
cause sites will just block tor - and then all those people that 
use tor for advancing human rights around the world, will lose 
the platform they need to do that, without being persecuted, 
cause they criticised something.

Re: WTF! new in class is static?!?!

[KingJoffrey via Digitalmars-d-learn]

On Thursday, 7 June 2018 at 21:57:17 UTC, Steven Schveighoffer 
wrote:


Yep, long-standing issue: 
https://issues.dlang.org/show_bug.cgi?id=2947


Almost a decade old!

-Steve


Another reason why I still refuse to bring my code to D.

As if the module not respecting class encapsulation was not 
enough (see my rants about it elsewhere), D even allows two class 
instances to share non static mutable data!!


wtf!

--
import std.stdio;

class A
{
int[] c = [3,3];
}

void main()
{
A ca = new A;
A cb = new A;

ca.c[0] = 44;

writeln(cb.c[0]);
// prints 44 (in C++, Java and C#, this would - correctly 
- print 3)

}
---

Re: Remember the Vasa! by Bjarne Stroustrup

[KingJoffrey via Digitalmars-d]

On Saturday, 2 June 2018 at 00:49:04 UTC, Bastiaan Veelo wrote:


These are exactly the things that enable us to bring a very 
large code base to D. Not just faster or better, it makes the 
difference between impossible and possible. And we are 
engineers needing to solve real-world problems, not CS nerds 
that find these features merely interesting from a theoretical 
perspective. Stay tuned for an announcement...


Well, as a real world engineer, needing to solve real-world 
problems, and 'interested in' bringing large code bases to D, can 
you tell me why I cannot have an encapsulated class in D, but 
instead, I am forced to outsource that enscapsulation to the 
module?


When will the impossible, become possible?

Re: Installation on Ubuntu 18.04 is broken

[KingJoffrey via Digitalmars-d]

On Friday, 1 June 2018 at 21:21:25 UTC, IntegratedDimensions 
wrote:


Your failure is that D is not a major language. It's like 
saying that "No other dogs I've come across meow, why does this 
dog meow"? It's a cat stupid!! :0


Sorry. but I have already demonstrated, that in D, a dog can meow.

Actually it can do whatever the hell you want it too, because a 
dog can no longer be encapsulated to it's own microenvironment. 
In D, it's boundary structures are porous, and anything can leak 
in, or out.


This makes any interaction with the environment particuarly 
troublesome, for the dog.


Even a drop of water has better protection.

Re: Sealed classes - would you want them in D? (v2)

[KingJoffrey via Digitalmars-d]

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.

}
--

Re: Sealed classes - would you want them in D? (v2)

[KingJoffrey via Digitalmars-d]

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 
classes, you can mix in C# extension methods paradigm into D. 
Which is why I don't see any reason to add this.




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

Why should a c# programmer come to D, if, in order to keep 
private private, they have to resort to this. It makes no sense. 
They may as well just stick to C#.


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.

Re: Sealed classes - would you want them in D? (v2)

[KingJoffrey via Digitalmars-d]

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!

Re: Sealed classes - would you want them in D? (v2)

[KingJoffrey via Digitalmars-d]

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.

Re: Sealed classes - would you want them in D? (v2)

[KingJoffrey via Digitalmars-d]

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 
languages like C# or java and I think D has (accidentally) 
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?

Re: Sealed classes - would you want them in D? (v2)

[KingJoffrey via Digitalmars-d]

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 ...dadada.da...dada.


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.

Re: Sealed classes - would you want them in D? (v2)

[KingJoffrey via Digitalmars-d]

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

Re: Sealed classes - would you want them in D? (v2)

[KingJoffrey via Digitalmars-d]

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.

Re: Error about constructor calls in loops/labels, but there are no loops and labels?

[KingJoffrey via Digitalmars-d]

On Sunday, 20 May 2018 at 03:13:12 UTC, Neia Neutuladh wrote:


While it's mildly refreshing that you found something new to 
talk about, it would be nice if you found something productive 
to say. You're merely complaining that a person who has spent 
about two decades on D (for free), who has decades more 
experience with compilers, who is the main contributor to the D 
compiler, and who has a track record of being right a lot, is 
influential when it comes to changes to the language.


da da dah da dah dah dah da



Think of it this way.. that I'm injecting some quantum 
fluctuations into the D universe, in the hope that it triggers an 
inflationary period - otherwise the D universe will fizzle and 
die...


Creating another universe from scratch, is a long drawn out 
process..who want's to sit around for that to happen?

Re: Override member variables

[KingJoffrey via Digitalmars-d]

On Saturday, 19 May 2018 at 18:09:56 UTC, Gheorghe Gabriel wrote:

And of course, you cannot override private members.


wtf!

what do you mean we cannot override private members!

that's at the core of D!

what's with you anyway!

(ohh. to those new to the forums, that's friendly sarcasm, cause 
as you know, we're all friends in D - whether you like it or not).

Re: Error about constructor calls in loops/labels, but there are no loops and labels?

[KingJoffrey via Digitalmars-d]

On Sunday, 20 May 2018 at 00:05:39 UTC, Jonathan M Davis wrote:


As I understand it, in general, Walter is against doing ...


All I ever hear, is walter walter walter

mmm..takes me back to my childhood..

https://www.youtube.com/watch?v=-yZHveWFvqM

Re: Sealed classes - would you want them in D? (v2)

[KingJoffrey via Digitalmars-d]

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.

Re: Sealed classes - would you want them in D? (v2)

[KingJoffrey via Digitalmars-d]

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.

Re: Sealed classes - would you want them in D? (v2)

[KingJoffrey via Digitalmars-d]

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.

Re: Sealed classes - would you want them in D? (v2)

[KingJoffrey via Digitalmars-d]

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

Re: Sealed classes - would you want them in D? (v2)

[KingJoffrey via Digitalmars-d]

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

Re: Sealed classes - would you want them in D? (v2)

[KingJoffrey via Digitalmars-d]

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

Re: Sealed classes - would you want them in D? (v2)

[KingJoffrey via Digitalmars-d]

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

Re: Sealed classes - would you want them in D? (v2)

[KingJoffrey via Digitalmars-d]

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.

Re: Sealed classes - would you want them in D? (v2)

[KingJoffrey via Digitalmars-d]

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.

Re: Sealed classes - would you want them in D? (v2)

[KingJoffrey via Digitalmars-d]

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.

Re: Sealed classes - would you want them in D? (v2)

[KingJoffrey via Digitalmars-d]

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.

Re: Sealed classes - would you want them in D? (v2)

[KingJoffrey via Digitalmars-d]

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.

Re: Sealed classes - would you want them in D? (v2)

[KingJoffrey via Digitalmars-d]

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.

Re: Sealed classes - would you want them in D? (v2)

[KingJoffrey via Digitalmars-d]

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.

Re: Sealed classes - would you want them in D? (v2)

[KingJoffrey via Digitalmars-d]

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)

Re: Sealed classes - would you want them in D? (v2)

[KingJoffrey via Digitalmars-d]

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

Re: Sealed classes - would you want them in D? (v2)

[KingJoffrey via Digitalmars-d]

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

Re: Sealed classes - would you want them in D? (v2)

[KingJoffrey via Digitalmars-d]

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.


[..dadadadada...]


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

Re: Sealed classes - would you want them in D? (v2)

[KingJoffrey via Digitalmars-d]

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.

Re: Sealed classes - would you want them in D? (v2)

[KingJoffrey via Digitalmars-d]

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.

Re: Sealed classes - would you want them in D? (v2)

[KingJoffrey via Digitalmars-d]

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 = 

int var2 = 2;
ip = 
}

--

Re: Sealed classes - would you want them in D? (v2)

[KingJoffrey via Digitalmars-d]

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.

Re: Sealed classes - would you want them in D? (v2)

[KingJoffrey via Digitalmars-d]

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.

Re: Sealed classes - would you want them in D? (v2)

[KingJoffrey via Digitalmars-d]

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

Re: Sealed classes - would you want them in D? (v2)

[KingJoffrey via Digitalmars-d]

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!

}

Re: Sealed classes - would you want them in D? (v2)

[KingJoffrey via Digitalmars-d]

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.

Re: Sealed classes - would you want them in D? (v2)

[KingJoffrey via Digitalmars-d]

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.

Re: Sealed classes - would you want them in D? (v2)

[KingJoffrey via Digitalmars-d]

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.

Re: Sealed classes - would you want them in D? (v2)

[KingJoffrey via Digitalmars-d]

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.

Re: Sealed classes - would you want them in D? (v2)

[KingJoffrey via Digitalmars-d]

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

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

[KingJoffrey via Digitalmars-d]

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


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

No, not sealed as in Scala.

No, not sealed as in C#

sealed as in oxford dictionary (close securely, non-porous).

when sealed is applied on the class, this means the class is 
sealed.


the sealed attribute only makes sense within a module, and 
affects nothing outside of the module.


When sealed is applied to the class, then, interfacing to a class 
within a module, from code outside that class - but still within 
the module, can now only occur via the published interface of the 
class.


outside code in the module, can no longer directly access your 
private parts!


The class is sealed.

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Thursday, 17 May 2018 at 01:36:47 UTC, KingJoffrey wrote:


how about adding a 'private' attribute on the class, which 
would mean, private inside the class is only accessible inside 
the class.


I presume the private attribute on the class, is not currently 
valid in D?




or even 'sealed' (as in the actual meaning of the word)

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Wednesday, 16 May 2018 at 16:43:31 UTC, Walter Bright wrote:


I had no idea. It's either parallel gestation of a great idea, 
or they took it from D!


the splitting of the atom was a great idea too..now the world is 
on the brink of destruction (according to some).


how about adding a 'private' attribute on the class, which would 
mean, private inside the class is only accessible inside the 
class.


I presume the private attribute on the class, is not currently 
valid in D?


This seems unlikely to break anything, while giving the 
programmer back the control to strategically define interfaces 
that *must* be used.


My neighbour likes to back his car into his driveway.
To do so, he drives over my lawn in turns into his driveway.
Why? Because he doesn't respect the interface! (his driveway, is 
his interface, but cause I have no barrier around my lawn, he can 
do what he likes).


Yeah, i know, one class per module might solve this, sure...(put 
a fence around your lawn approach - but I like it without a 
fence.).


I really do prefer the 'program to interfaces' approach, and, 
occasionally I would like to have more than one class in the same 
module (where I deem that appropriate), and still have their 
interfaces respected.


I cannot do this in D.

Is there no way this can be accomodated in D (without breaking 
how things currently work)?

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Wednesday, 16 May 2018 at 13:09:22 UTC, Jesse Phillips wrote:
That isn't a bug. What is the software use case? How did this 
case differ because someone did this?




Sorry, I didn't realise my example was so complex.

Hang on... I'll just put it all into a use case diagram in my new 
UML tool... I'll get back to you on this soon...

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Wednesday, 16 May 2018 at 13:09:22 UTC, Jesse Phillips wrote:


Global variables and singletons are also frowned on, but call 
it bad coding not a bug.


Come on, really? that's just word play, much like the use of the 
'private' declaration in a class (in D that is).


(also, this was not an enterprise application I was developing 
(D's not ready by a long shot, for the big time, in my opinion) - 
it was just some code I was playing with in a sandbox (i.e a 
module).

Re: auto: useful, annoying or bad practice?

[KingJoffrey via Digitalmars-d]

On Monday, 30 April 2018 at 21:11:07 UTC, Gerald wrote:

So I'm curious, what's the consensus on auto?


In the example below, what would I use, besides auto?


module test;

void main ()
{
import std.stdio : writeln;
auto result = newKing("King Joffrey");
writeln(result.getName);
}

auto newKing(string name)
{
class King
{
private string _name;
public string getName() { return this._name ~ " : the one 
true king!"; }

this() { this._name = name; }
}

return new King;
}

--

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Wednesday, 16 May 2018 at 10:24:02 UTC, Jonathan M Davis wrote:
Part of the problem with D's spec is that it's basically both 
trying to be a specification for the language and be a way to 
explain the language to the typical programmer, and those 
aren't really compatible goals. We really need to have anything 
intended to teach the language be separate from the spec..


The specification (the one available above under 'Documentation', 
can be simply be 'annotated', and therefore serve more that just 
'folks like compiler writers'.


Those who don't need the annotations, can just ignore the 
annotations.


I'm not talking 'tutorials' here, just some extra, helpful 
explanation.


The C# Programming Language, 4th Edition, by Anders Hejlsberg (et 
al) is still one of my favourite all time books (because of the 
mix of specification and expert annotations).

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Wednesday, 16 May 2018 at 06:17:51 UTC, Uknown wrote:


`public` by default is again not a problem. Just apply 
`private` as necessary.


it's not a problem 'if' you 'remember' to use 'private'.

private 'within the module' is also not a problem, 'if' you 
'remember' that, when using private to encapsulate your class.


Again, other mainstream languages have already learn the lesson 
here, as to why public might not be a great 'default'.


knowledge is useful, I get it. so are safe defaults.

Also, if you want the rust style `private`, D offers `package`, 
which means private to the modules contained by a package.


Thanks for clarifying this.

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Wednesday, 16 May 2018 at 06:11:13 UTC, Tobias Müller wrote:

KingJoffrey  wrote:

actually, private is default in Rust.

public is default in D.

also, in Rust, private is private within the module, *and* its 
descendants.


I don't believe that is the case in D (someone correct me if 
I'm wrong)


The point is, that the module is the abstraction boundary.


Yeah, but "The unit of object encapsulation in D is the class."
 - page 175, The D Programming Language, 2010, Andrei 
Alexandrescu.


They cannot both be true. And this leaves room for confusion for 
new comers to D,

unless they all get to page 200 in time, where it says:

"In all contexts, private has the same power: it restricts symbol 
access to the current module (file). This behavior is unlike that 
in other languages, which limit access to private symbols to the 
current class only. ...  If class-level protection is needed, 
simply put the class in its own file."


Now something like that in the spec I mentioned (on the D 
website), would not do any harm to the spec, would it?

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Wednesday, 16 May 2018 at 06:11:13 UTC, Tobias Müller wrote:

KingJoffrey  wrote:

actually, private is default in Rust.

public is default in D.

also, in Rust, private is private within the module, *and* its 
descendants.


I don't believe that is the case in D (someone correct me if 
I'm wrong)


The point is, that the module is the abstraction boundary.


oh, sorry, I thought your point was that "Visibility in Rust is 
similar to D."

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Wednesday, 16 May 2018 at 05:59:17 UTC, Tobias Müller wrote:

KingJoffrey  wrote:
The problem is not so much D, but that C++/Java/C# 
programmers, and many from other languages (Go, Rust) will 
expect private to mean private...not private..depending on


Well, that's not entirely true.
Visibility in Rust is similar to D.
There's no one true language semantics that holds for all 
languages. That's

the point of having different languages.


Also, my point was not that different languages should not be 
different.


My point was to be aware of the potential for misunderstandings 
of what 'most' people would expect to hold true.


And that point comes back to the very reason I interjected into 
this discussion (some time back) - because someone though it 
might be a great idea to introduce a sealed class - but how many 
people would end up thinking that the keyword 'sealed' means 
"sealed as in Scala, not as in C#".


My point holds up, because 'most' (not all, sure) programmers use 
languages where terminology means the same thing. And I think D 
needs to be conscious of this when using well known 
terminologies/concepts, because what I like most about D, is that 
I can bring my existing knowledge from other mainstream 
langauges, and start using D productively, very quickly. I cannot 
say the same for Rust and Go. I almost DO have to go and read the 
spec before I start using it.

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Wednesday, 16 May 2018 at 05:59:17 UTC, Tobias Müller wrote:

KingJoffrey  wrote:
The problem is not so much D, but that C++/Java/C# 
programmers, and many from other languages (Go, Rust) will 
expect private to mean private...not private..depending on


Well, that's not entirely true.
Visibility in Rust is similar to D.
There's no one true language semantics that holds for all 
languages. That's

the point of having different languages.


actually, private is default in Rust.

public is default in D.

also, in Rust, private is private within the module, *and* its 
descendants.


I don't believe that is the case in D (someone correct me if I'm 
wrong)

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Wednesday, 16 May 2018 at 05:43:58 UTC, KingJoffrey wrote:


Also, having a C++ like spec, written by the elite, for the 
elite, and then everyone else has to wait until some kind 
person explains the spec, is really not a great model.


It's equivalent to the elitist view of trickle down economics - 
which is not working in my country.


oh, and btw, even the elite don't truly understand the tool. 
they, they like all people, understand bit and pieces of this and 
that, some bits more than others, some less than others.


Please find me the number of C++ programmers who understand C++.

https://www.youtube.com/watch?v=YAP_xTsapW0

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Wednesday, 16 May 2018 at 04:25:40 UTC, Jonathan M Davis wrote:
I think that really what you want is something that's geared 
more towards teaching the language. The ways that the language 
spec needs to be improved really revolve around making it a 
proper spec, which means making it far more precise, not making 
it more amenable to folks reading it in order to learn the 
language. But unfortunately, what we have right now is kind of 
in the middle. It's not precise enough to really be a proper 
spec, and it's generally terse enough that it's harder to use 
it as a learning resource (though it usually has the necessary 
information in it).


- Jonathan M Davis


Also, having a C++ like spec, written by the elite, for the 
elite, and then everyone else has to wait until some kind person 
explains the spec, is really not a great model.


It's equivalent to the elitist view of trickle down economics - 
which is not working in my country.

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Wednesday, 16 May 2018 at 04:25:40 UTC, Jonathan M Davis wrote:
The ways that the language spec needs to be improved really 
revolve around making it a proper spec, which means making it 
far more precise, not making it more amenable to folks reading 
it in order to learn the language.


I love it. I'll add that to my list of 'D forum qoutes'.

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Wednesday, 16 May 2018 at 03:52:43 UTC, Uknown wrote:


One is expected to know the tool they are using. There is 
nothing elitist about that.




That is a pathetic, and yet another elitist view.

If programmers never programmed until they 'understood the tool', 
there would not be 20+ million programmers in the world.


How many C++ programmers understand C++ (let alone have read the 
spec).


The same can be asked for pretty much any other language.

Learning is still a gradual process - except for elitists it 
seems, who expect you to know everything up front.


There is no if. You know what the stop sign means because 
someone told you what it means. private means it is only 
available to the module. It is entirely the fault of the user 
for not reading the docs.




Another elitist view.



Its actively being improved, but in this case it was more than 
adequate. The spec was pretty clear that private applies to 
modules.


I disagree.

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Wednesday, 16 May 2018 at 03:12:03 UTC, Jonathan M Davis wrote:


It specifies what private does quite accurately. If you want 
something that's trying to point out how you might 
misunderstand the spec or what problems you might run into, 
you'll need to read something like Ali's book. The spec is 
telling you how the language works, not trying to tell you how 
you might misunderstand it or what misakes you might make. And 
the information it gives there is quite accurate and complete. 
Honestly, I would have thought that knowing that private is 
private to the module would be plenty to understand what that 
then means for structs or classes, but everyone thinks 
differently and absorbs or misses different pieces of 
information. But ultimately, anyone who doesn't understand 
something is free to ask in places like D.Learn or 
stackoverflow.


- Jonathan M Davis


To suggest that "Symbols with private visibility can only be 
accessed from within the same module" - is all you need to know 
(if you're lucky to find the needle in the haystack), is kinda 
elitist.


People expect norms to be the norm. That's entirely reasonable.

If I see a STOP sign while I'm driving, I expect it means STOP, 
not 'STOP..if.."


If I see private, I expect it means private, not 'private..if'.

The language reference could, and should do better.

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Tuesday, 15 May 2018 at 19:56:58 UTC, Patrick Schluter wrote:

On Tuesday, 15 May 2018 at 02:32:05 UTC, KingJoffrey wrote:

On Tuesday, 15 May 2018 at 02:00:17 UTC, 12345swordy wrote:

On Tuesday, 15 May 2018 at 00:28:42 UTC, KingJoffrey wrote:

On Monday, 14 May 2018 at 19:40:18 UTC, 12345swordy wrote:

[...]


If 'getting a module to respect the enscapsulation 
boundaries the programmer puts in place would change the 
language so 'fundamentally', then the language 'already' 
presents big problems for large complex application 
development.



Evidence for this claim please.


- Object independence
- Do not violate encapsulation
- Respect the interface

All large software projects are done in (or moving toward) 
languages that respect these idioms.


Those that don't, are the ones we typically have problems with.

Isn't that evidence enough?


That's not evidence, that's pure opinion. There's not a shred 
of data in that list.


Actually, that is the history of the evolution of programming 
large, complex systems, that have to be to correct, safe, and 
amenable to change.


What other approach would work?

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Tuesday, 15 May 2018 at 21:05:10 UTC, Jonathan M Davis wrote:


Though if someone expects to be able to just jump into any 
language and use it without reading up on how it works, they're 
just shooting themselves in the foot. And surprisingly often, 
that seems to be how many folks operate.




And that comment is a little unfair don't you think?

The best clarification I can find, regarding how D treat's 
private, is from this tiny little sentence (from which, I assume, 
the programmer is now meant to understand it's full implications):


"Symbols with private visibility can only be accessed from within 
the same module"


https://dlang.org/spec/attribute.html#visibility_attributes

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Wednesday, 16 May 2018 at 02:15:45 UTC, KingJoffrey wrote:


"The unit of object encapsulation in D is the class." - page 
175, The D Programming Language, 2010, Andrei Alexandrescu.


What it really should have included, locally, within that same 
section, is the implications of this 'encapsulation' with 
regards to how 'facebook like friendship' is a core design 
component of the D module.


i.e, on the next line, Andrei could have continued..

"However, if your class is contained within a module, then this 
encapsulation barrier kinda breaks down, because everything in 
the module becomes a friend of that class, whether you like it 
or not. You have no say in the matter. If you don't like it, 
fine, but that's how D does things, so just be careful what you 
put in a module".


Although, to be fair to Andrei, once you get to page 200 (25 
pages after the above comment about class encapsulation), you do, 
finally, get some clarification:


"In all contexts, private has the same power: it restricts symbol 
access to the current module (file). This behavior is unlike that 
in other languages, which limit access to private symbols to the 
current class only. ...  If class-level protection is needed, 
simply put the class in its own file."

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Tuesday, 15 May 2018 at 21:05:10 UTC, Jonathan M Davis wrote:


Ultimately, if newcomers don't want to be tripped up on stuff 
like this, their best bet is probably to read books like 
Andrei's "The D Programming Language" and Ali's "Programming in 
D."




"The unit of object encapsulation in D is the class." - page 175, 
The D Programming Language, 2010, Andrei Alexandrescu.


What it really should have included, locally, within that same 
section, is the implications of this 'encapsulation' with regards 
to how 'facebook like friendship' is a core design component of 
the D module.


i.e, on the next line, Andrei could have continued..

"However, if your class is contained within a module, then this 
encapsulation barrier kinda breaks down, because everything in 
the module becomes a friend of that class, whether you like it or 
not. You have no say in the matter. If you don't like it, fine, 
but that's how D does things, so just be careful what you put in 
a module".

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Tuesday, 15 May 2018 at 15:19:33 UTC, Jesse Phillips wrote:

On Tuesday, 15 May 2018 at 10:19:58 UTC, KingJoffrey wrote:
My own code in D had bugs, cause I didn't realise all my 
private parts were not just visible, but accessible by all the 
so called 'friends' around me. They could reach in a do 
whatever they want! Without my consent!


You've peaked my interest, could you give some details on one 
or more of these bugs?


It's simple.

Write a non-member function, contained in the same module as a 
class, and accidently use a private class member instead of the 
public getter/setter defined by the interface of that class.


It's human error, that will occur time and time again, but will 
*never* get picked up in D, except through a debugging session, 
because D does not consider this an error.


How can it, if private is not really private?

Now the burden is back on the programmer again.

Be careful what you put into a module.

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Tuesday, 15 May 2018 at 14:34:07 UTC, bachmeier wrote:


I think I'm missing something. Why is it a problem that you can 
do this? How do other languages prevent you from doing it?


C# example (silly, but it demonstrates the point).

The problem is not so much D, but that C++/Java/C# programmers, 
and many from other languages (Go, Rust) will expect private 
to mean private...not private..depending on


They will expect the interface they defined, to be respected.

Then they'll start asking..wtf!@$#?   .. and end up in long 
threads like this one, trying to work out why the world is upside 
down (or seems like it).


And don't get me started on public being the default in D .. 
cause at some point..I gotta get some sleep.


--
public class Program
{
public static void Main(string[] args)
{
Person p = new Person();
//p.name = "King Joffrey"; // dude. this is private!
}
}

public class Person
{
private string name;
public string getName() { return name; }
}

---

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Tuesday, 15 May 2018 at 07:23:55 UTC, Jonathan M Davis wrote:


The prime one is unit tests. The fact that they can access the 
private variables is invaluable for testing the state of an 
object. In C++, I have always have to make all of the tests 
friends of the class so that they can access the internals for 
testing. In D, I don't have to worry about any of that, and the 
tests don't affect the public interface of the class at all.


ok. so the 'for' side arguments, for embracing Facebook style 
friendship in D:


- Voldemort types (cause yeah...we all use them so often).
- Unit tests (dare I the same ;-)

Actually, I kinda get it for unit tests.

Surely there's more??


The assumption is that anything that goes in the same module 
can either reasonably be treated as friends, or it doesn't 
matter if they are.


Well, we already know what disasters can occur from facebook 
style friendships.


My own code in D had bugs, cause I didn't realise all my private 
parts were not just visible, but accessible by all the so called 
'friends' around me. They could reach in a do whatever they want! 
Without my consent!


And btw, people grabbing your private parts without your explicit 
consent, is a really serious matter! Just ask those in the me-too 
movement.


Why should a programmers code be exempt from such considerations?

Basically all of the same arguments that you're giving against 
having everything in the module being treated as friends of 
each other can be given against having friends in the first 
place. It's just that D makes it implicit within the module.




No. In C++, you only declare friends as part of your defined 
interface.


That's kind different to 'everyone around you is your friend. so 
you need to deal with it'.


They are not the same thing, and have to be approached 
differently.

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Tuesday, 15 May 2018 at 05:59:44 UTC, Mike Parker wrote:


Jonathan's right. We're just not going to agree on this.


The purpose of discussion is not necessarly to get one side to 
agree with other side.


You can keep your grouping and get your strict encapsulation 
like so:


// foo/bar/baz/package.d
module foo.bar.baz;
public import
foo.bar.baz.a,
foo.bar.baz.b,
foo.bar.baz.c,
foo.bar.baz.funcs;

The client need neither know nor care that everything is in 
separate modules and you get your strict encapsulation. You can 
still share items between modules via package protection, and 
within specific package hierarchies via package(packageName). 
And even better, you now have less code per module to reason 
about (re: one of your earlier arguments against the current 
behavior).


Fine. If I take your solution above, and ensure that every class, 
goes into it's own module, and that a module containing a class, 
contains nothing other than a single class (i.e no free 
functions), then sure, I end up where I am now, with C++/Java/C# 
- i.e a good place, where I feel comfortable. My declared 
interface is respected.


Why do I need D then? i.e. under what circumstances, would I want 
to put something extra into the module, so that it can abuse the 
declared interface of my class?


Can you give me some examples?

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Tuesday, 15 May 2018 at 04:46:18 UTC, Jonathan M Davis wrote:
Pretty much the worst that happens is you accidentally use a 
member variable directly instead of using a property function 
to access it, and that's rarely a big deal. Often, it's even 
desirable.


I'll keep that argument for the status quo, and will be sure to 
put it in the DIP.

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Tuesday, 15 May 2018 at 04:46:18 UTC, Jonathan M Davis wrote:


If you really insist on the viewpoint that class encapsulation 
means that nothing outside of that class can access any of its 
private members, then what D does definitely breaks 
encapsulation. But having friends in C++ already provides a way 
to break that.


No. That is not true.

friend is explicately part of the declared interface.

D on the otherhand, tells you who your friends are.

Your interface doesn't have a say in it anymore.

When your declared interface is moot, your enscapsulation is also 
moot.



Regardless, I think that it's quite clear that we're not going 
to convince KingJoffrey of anything, and it's unlikely that 
he's going to convince us - though honestly, with that 
username, I have to wonder if he's complaining about this issue 
to just screw around with us for fun. But even if he's 
completely serious, I think that it's clear that at best we're 
going to agree to disagree.


- Jonathan M Davis


I prefer to think of it as a discussion. Even though I'm right ;-)

But in any case, i feel I've presented some worthwhile arguements.

The only arguments I've got so far from the other point of view, 
is that's how D does it. If you don't like it, go wrute a DIP.

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Tuesday, 15 May 2018 at 04:22:30 UTC, Mike Parker wrote:

On Tuesday, 15 May 2018 at 02:32:05 UTC, KingJoffrey wrote:



- Object independence
- Do not violate encapsulation
- Respect the interface


This is what I don't get from your position. What is 
encapsulation? Here's what Wikipedia says [1]:


"Encapsulation is used to hide the values or state of a 
structured data object inside a class, preventing unauthorized 
parties' direct access to them. Publicly accessible methods are 
generally provided in the class (so-called getters and setters) 
to access the values, and other client classes call these 
methods to retrieve and modify the values within the object."


This has been my understanding of encapsulation since I first 
learned of it years ago. How is this broken in D? Only if you 
insist on viewing it in a strictly theoretical sense. As a 
matter of practical reality, it is not broken.


If you have access to the internals of the class, you also have 
access to the rest of the module. No client of the class 
outside of the module has any access to the implementation. I 
showed you an example earlier of how silly it would be to force 
the rest of the module to use some sort of "module private" 
interface.


The class in D *is* encapsulated. The interface *is* respected. 
I'm not sure what you mean by object independence.



[1] 
https://en.wikipedia.org/wiki/Encapsulation_(computer_programming)


Yes, it's a vague word which can be interpreted different ways.

I primarily mean the more abstract notion of 'boundaries' and 
'interfaces'.


The concept is well presented in this keynote at ACCU 2018:

https://www.youtube.com/watch?v=IP5akjPwqEA

E.g. passing from one room to another, via a door. The door 
presents the boundary, and the interface through which you access 
each room. You cannot go star trek style (yet) and just beam from 
one room to the other.


'Beam me up scotty' is just for the movies (as far as I know ;-)

Also, if there is no boundary between the orange room and the 
blue room, how would I get from the orange room to the blue room 
- or vica versa?


The only reality our brains can perceive, is the reality made of 
from boundaries and interfaces. We cannot hold all of reality in 
our head. We have to break things down into little self-contained 
chunks, and then understand how the chunks connect together.


It becomes particularly important when trying to understand 
complexity (of any kind).


943294432432812  // grr!

943_294_432_432_812 // nice

the underscore represent the boundary.
the information between boundaries is now encapsulated (because 
of that boundary)


Now, back to D...

in this example code below, the D module does not respect the 
boundary of the object.


That is, the module can beam into the object without going 
through the interface.


I struggle to understand why the module is allowed to do this - I 
really cannot get my head around any valid reason for it - I'm 
just getting told, 'that's how D does it' -or - 'it doesn't 
really bother us'.


If I cannot control the interface, and have that respected by the 
module, then this allows the kind of bugs that actually lead me 
to working out that private is not really private at all.


And that bug would not have happened in C++/Java/C# - or, as far 
as I know, Rust and Go. They would have all respected the 
boundary.


D has chosen to allow the module to disrespect the interface. Why?

(and don't tell me it does - cause the code below clearly 
demonstrates that it does not)


===
module test;

void foo()
{
Person p = new Person("King Joffrey");

// this completely bypasses my interface
// (i.e. the boundary that I set up between the class and the 
module)

p._name = "New King";

}

class Person
{
private string _name;

public void setName(string name)
{
this._name = name;
}

public this(string name)
{
_name = name;
}

}

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Tuesday, 15 May 2018 at 03:32:22 UTC, Norm wrote:


I'm seeing the opposite, more and more large applications 
adopting Python as much as possible and replacing big chunks of 
the C++ core and leaving only those C++ chunks where 
performance is all that really matters.


Encapsulation boundaries are completely arbitrary and where D 
choses to draw the line works very well in practice.


Bye,
Norm


"Encapsulation boundaries are completely arbitrary.."

I love it.

We have so much to look forward to, as more and more languages, 
and more and more quality software projects, embrace that 1950's 
idiom.

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Tuesday, 15 May 2018 at 02:00:17 UTC, 12345swordy wrote:

On Tuesday, 15 May 2018 at 00:28:42 UTC, KingJoffrey wrote:

On Monday, 14 May 2018 at 19:40:18 UTC, 12345swordy wrote:


A slippery slope fallacy isn't helping your case. Write a DIP 
if it bothers you so much, as it changes the languages 
fundamentally.



Alexander


If 'getting a module to respect the enscapsulation boundaries 
the programmer puts in place would change the language so 
'fundamentally', then the language 'already' presents big 
problems for large complex application development.



Evidence for this claim please.


- Object independence
- Do not violate encapsulation
- Respect the interface

All large software projects are done in (or moving toward) 
languages that respect these idioms.


Those that don't, are the ones we typically have problems with.

Isn't that evidence enough?

D modules provide uncontrolled violation of encapsulation (i.e 
can bypass the interface), and completely undermine these 
established idioms.


D modules, will let anyone (within that module) access your 
wallet and take whatever they want.


http://www.ccs.neu.edu/research/demeter/demeter-method/LawOfDemeter/paper-boy/demeter.pdf




But C++/Java/C# users all expect private to mean private,


We expect that users C++/Java/C# to know that D is not 
C++/Java/C# and to read the specification.


Again write a DIP if this bothers you. You are not going to 
make any language changes by ranting about it on the forums.


yeah.. I get it.. don't discuss anything, don't explore ideas or 
why others might think differently, just go off and write a DIP. 
That's why DIP's are so often poorly written and not worth the 
time of those that have to look at them.


I think such talk is just a way to shut down the converation, to 
be honest.


Based on this discussion so far, what I've gauged, is that 
spending the effort to write a dip, would be pointless (at least 
at this stage).


If D ever takes off (and I'm not sure it will, precisely because 
of the way it disregards those idioms I mentioned), then more 
pressure will come on D to change - and perhaps then sufficient 
support for a DIP would be there. But I honestly don't see how it 
can take off, unless if first respects those idioms.

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Monday, 14 May 2018 at 19:40:18 UTC, 12345swordy wrote:


A slippery slope fallacy isn't helping your case. Write a DIP 
if it bothers you so much, as it changes the languages 
fundamentally.



Alexander


If 'getting a module to respect the enscapsulation boundaries the 
programmer puts in place would change the language so 
'fundamentally', then the language 'already' presents big 
problems for large complex application development.


Little old me ranting about it in some DIP isn't going to do much.

D is great for small, quick stuff though - I'll give it that. I 
enjoy using D for small stuff.


But C++/Java/C# users all expect private to mean private, as it 
should, and will, like me, get a nasty shock when they come over 
to D, and discover it my mistake, as I did.


It was only through debugging my code, did I realise I had 
disprespected the boundaries I set up, because the module let me 
do it, and the compiler thought that's what I must have wanted. I 
simply could not have made that mistake in any of the other 
langauges I use.


Clearly others take a different perspective on this issue, that's 
fine, I just don't get the case they're trying to make. It hasn't 
made any sense to me thus far.


Removing respect for encapsulation boundaries, in order to 
avoiding the need for using C++ like 'friend', sounds a bit dodgy 
to me. No matter how much I think about it, I'd rather have those 
boundaries and be forced to use friends.

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Monday, 14 May 2018 at 07:59:06 UTC, Jonathan M Davis wrote:
.. In addition, we rely on function encapsulation for Voldemort 
types...


Actually, we rely on encapsulation (boundaries) for a lot more 
than that.


How do we get from the orange room to the blue room, if there is 
no boundary?


https://www.youtube.com/watch?v=IP5akjPwqEA

(great quote at the end btw - but watch the whole thing first - 
it'll make more sense)

Re: Is D releasing too often?

[KingJoffrey via Digitalmars-d]

On Monday, 14 May 2018 at 07:20:48 UTC, Joakim wrote:


I thought 6/year was an ambitious schedule when announced and I 
wonder if it isn't putting too much strain on our few release 
maintainers, maybe 3-4 releases/year would be a more gradual 
bump up.


This is what happens to programming langauges and software 
development, when competition becomes the main game.


Thank god for Redhat - still on gcc 4.8.5 .. god bless them ;-)

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Monday, 14 May 2018 at 07:03:35 UTC, Dukc wrote:



module test;
void main() { foo.i = 2; }
void foo() { static int i = 1; }



nice, .. I like it... I mean who really needs a function 
interface anyway?


D may as well just get rid of that encapsulation concept too, 
since the class interface is pretty much moot in D modules.


Maybe.. we should even, just completely get rid of functions and 
classes - as well as all that other stupid so-called 'structured 
programming' crap, which just restricts us, and revert to 'real' 
programming - using just line numbers and goto statements. Then, 
finally, we programmers can do whatever we want again.


Local reasoning...it's so old-school.

Re: Module-level privacy

[KingJoffrey via Digitalmars-d]

On Sunday, 13 May 2018 at 05:11:16 UTC, Neia Neutuladh wrote:
Nobody's getting worked up about this, and nobody's telling you 
to stop talking about it. There have been suggestions that you 
write up a DIP for it. This is a standard process for 
suggesting improvements to D.


Your complaint is about protection, not about classes. It 
should affect all definitions. Perhaps you simply don't expect 
type-level encapsulation for structs and top-level declarations.


First, this thread was about extending the capabilities of 
classes in D with some new attribute/capability - sealed.


I thought it was first important to point out, in this thread, as 
opposed to a separate thread, that classes in D are already 
problematic, because modules do not respect the encapsulation 
boundaries of classes, and any discussion about further extending 
classes should be approached with great caution - because the 
problem will only become even more entrenched.


Second, writing a DIP is pointless, since Walter likes the idea 
that the module doesn't protect the encapsulation boundary of the 
class. Now if Walter thinks that's fine, what is a DIP going to 
do? I mean really. I have better things to do.


Third, those who responded to my caution are the ones that should 
have created a separate thread, not me.


Finally (and I do mean finally), my concern about the loss of the 
encapsulation boundary of classes in D, has a very real impact on 
the quality and maintainability of software systems developed in 
D. That the designer of D apparently thinks otherwise, baffles me.

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Sunday, 13 May 2018 at 02:10:31 UTC, Uknown wrote:


Again, all you have to do is put class Person in a separate 
module.


This is such a nonsense solution. Why do you keep proposing it?

Is this you way to effectively sweep the problem under the carpet?

For me, a module presents the opportunity to group objects into a 
larger working unit.


But since D does not respect the encapsulation of objects, one 
has to revert to your solution, or mine (which is, if you're 
solution to a problem requires the use of classes, then go use a 
progamming language that respects the encapsulation boundary of 
classes).

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Sunday, 13 May 2018 at 02:10:31 UTC, Uknown wrote:
And please, if this bothers you so much, start a new thread. 
You're spamming someone else's feature request by going off 
topic.


yeah, I know how much *you* (and many others) would like to 
shutdown any discussion about the absurd way in which classes are 
treated in D. It's a touchy topic it seems.


Now, if I were having this discussion with myself, your comment 
about spamming the topic 'might' be correct.


As it is though, everyone involved in the discussion, including 
yourself, is spamming the topic, in that case.


so take your own advice. create a new thread, and have a go at me 
there instead.


When someone creates a topic about extending the capacity of 
classes in D, I will always feel the urge to remind them, that 
classes in D are a complete joke - and that you shouldn't bother 
using them. Better to use another language that has the capacity 
to respect the encapsulation barrier of the class.

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Saturday, 12 May 2018 at 18:19:48 UTC, Jonathan M Davis wrote:


I have never seen encapsulation issues where someone 
accidentally uses some private piece of a class or struct by 
accident elsewhere in the module, and the code therefore ends 
up with a bug.


Then you've never seem me program.

That bug you mention, is something that has often popped up in my 
program, because the compiler didn't warn me - hey, that stuff is 
private, shouldn't you be using the getter, or setter.


This loss of encapsulation, is why I no longer use classes in D.

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Saturday, 12 May 2018 at 18:36:59 UTC, Walter Bright wrote:

On 5/12/2018 9:42 AM, Mike Parker wrote:

Thank goodness we don't have to do this silliness.


I always thought the 'friend' business in C++ was an awful 
hack. But C++ didn't have modules, and modules are a much 
better solution to that problem.


Modules would only be a better solution, if, and only if, the 
programmer still had control over class level encapsulation.


At least 'friend' in c++, is in the control of the programmer.

D has decided the programmer doesn't need this control anymore, 
takes that control away, and gives it to the module - the 
programmer has no say in it - even if the programmer want's it 
private, the module overrides private!!


I would expect, that like me, 10's of millions of other 
programmers would not be comfortable with this.


That the '< 1000' D programmers think otherwise, doesn't make the 
case.


Go back and give the programmer control, as to whether the class 
or the module has the greater authority, and perhaps...then... D 
will attract more programmers.


Feel free to show the code below, to all the C#/C++/Java 
programmers out there - I'm sure they'll love what D has done 
with the class-module interaction.



module test;

import std.stdio : writeln;

void main()
{
Person p = new Person("King Joffrey");

writeln(p.getName); // I designed my class to present this 
interface.
writeln(p._name); // The module couldn't care less about your 
interface.


p._name = "King Walter"; // even worse, the module can 
de-throne the king!!

writeln(p._name);
}

class Person
{
private string _name;

public void setName(string name)
{
this._name = name;
}

public string getName()
{
return ProperName(this._name);
}

public this(string name)
{
_name = name;
}

private static string ProperName(string name)
{
return name ~ " : The one true king!";
}
}

===

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Saturday, 12 May 2018 at 13:38:18 UTC, Walter Bright wrote:


Mike's right. D's encapsulation model is designed around the 
module.


Actually, that is not true. If it were true, then I could do:


module test;
void main() { i = 2; }  // sorry, but i belongs to another unit 
of encapsulation

void foo() { int i = 1; }


D only breaks the encapsulation properties of classes, not 
functions.


Since the vast majority of programmers use classes as the basis 
for encapsulation, this surely presents a significant problem to 
those coming over to D, rightly expecting that encapsulation to 
be retained.


If a module is too large to be comprehended, it should be 
broken up into smaller modules, each with its encapsulated 
functionality.


But that's why we have functions and classes - which are their 
own level of smaller units of encapsulation. Blurring the 
boundary of encapsulation seems like a big step backward in terms 
of structured programming.


Each unit of code (a function, a class, a module) should respect 
the encapsulation properties of each other.


There's simply no point in using classes in D, as they have no 
capacity to encapsulate themselves (whereas function still retain 
this privilege)


Now if 'private' meant 'private to the class' (as most people 
would rightly expect), and the default if you had no attribute 
was, say, 'accessible to the module', then I could probably live 
with that, and I would start to use classes in D productively.


But when the class has lost its capacity to encapsulate, it's 
lost its purpose.


It is hard enough to hold a class in working memory so you can 
reason about.


Making us hold whole modules in memory so we can reason about the 
interaction between classes and modules, is just nonsense, in my 
opinion.

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Saturday, 12 May 2018 at 07:39:04 UTC, Jonathan M Davis wrote:
Ultimately, it's a tradeoff, and arguments can be made for and 
against. But in practice, it works extremely well. You're 
certainly free to not like this particular design choice, but 
it's one that most of us have no problem with, and I'd be 
shocked to ever see it change. So, you can be unhappy about it, 
but complaining isn't going to change anything. You're either 
going to have to just learn to live with it or not use D.


- Jonathan M Davis


I'm not so much complaining about it, as warning others of it.

D modules do NOT (cannot) respect the encapsulation of the class, 
and therefore, D modules containing classes, can very easily (to 
borrow a phrase from Bertrand Meyer) start to resemble "a chunk 
of Swiss cheese that has been left outside for too long..".


As for using D, this is why I don't really use D for anything 
other than small tasks - where I can happily revert to procedural 
type programming ( C like), and not have to worry about the 
issues of broken class encapsulation - which will almost 
certainly lead to unexpected side-effects, and create whole new 
'class' of problems that D programmers have to deal with.

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Saturday, 12 May 2018 at 07:19:47 UTC, rikki cattermole wrote:


I see no problem.

onlineapp.d(1): Error: label wtf is undefined


The 'Error' is my point. It's not possible to do this - which is 
a good thing.


D protects the encapsulation unit of the function from such abuse.

But the same is not true for classes.

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Saturday, 12 May 2018 at 06:38:16 UTC, rikki cattermole wrote:


Now move Person into its own module.
Boom errors.

This is how module systems should work and everything is 
working correctly :)


You will not convince us otherwise.


If D treated functions, like it treats classes, then you could do 
this in D (see below) - and the argument to get around the 
problems this causes, would be to put each individual function in 
it's own module.


That is in essence, your proposed solution to the problem with 
class encapsulation in D.



module test;

void main() { goto wtf; }

void foo()
{

wtf: return;

return;
}
==

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Saturday, 12 May 2018 at 04:29:32 UTC, Neia Neutuladh wrote:

On Friday, 11 May 2018 at 14:05:25 UTC, KingJoffrey wrote:
private is not private at all in D, and because of this, 
classes are fundamentally broken in D (by design apparently).


I find this amusing because D does things exactly like Java. In 
Java, two sibling nested classes can call private functions on 
each other. But nobody says that this makes Java's classes 
fundamentally broken.


Like, this just works in Java:

public class Protections {
public static class Bar {
private void bar() { System.out.println("bar"); }
}

public static class Baz {
private void bar(Bar b) { b.bar(); }
}

public static void main(String[] args) {
new Baz().bar(new Bar());
}
}



Come on, your code example misses my point completely.

Take this program below, for example, and tell me that class 
encapsulation is not broken in D:


===
module test;

import std.stdio : writeln;

void main()
{
Person p = new Person("King Joffrey");

writeln(p.getName); // I designed my class to return this.
writeln(p._name); // But D can bypass your intention 
completely.


p._name = "New King"; // even worse, D can nominate another 
king.

writeln(p._name);
}

class Person
{
private string _name;

public void setName(string name)
{
this._name = name;
}

public string getName()
{
return ProperName(this._name);
}

public this(string name)
{
_name = name;
}

private static string ProperName(string name)
{
return name ~ " : The one true king!";
}
}

==

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Friday, 11 May 2018 at 19:30:51 UTC, bauss wrote:
It's a problem to you, but not to me and I'm sure many others 
in the D community can agree that private being module level 
has a lot of benefits over private being "class-level".


These are the benefit I can see:

- it encourages more complex, ill-structured problem solving 
skills.


- it increases cognitive load on those seeking to understand the 
solution (cause now they have to take into accont the 'entire' 
module, as opposed to smaller encapsulated units of code within 
the module.)


We're back in goto land!

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Saturday, 12 May 2018 at 00:39:29 UTC, Mike Parker wrote:


Again, they're in the same module. From an encapsulation stand 
point, what does it matter that private members are within or 
without any specific set of curly braces? It only matters if 
you want to adhere to a purely conceptual view of 
encapsulation. From a practical view, it matters not one whit.






It matters, in the same sense, that it matters if you have a 
module, full of functions (which are encapsulated units of code), 
but your module has a whole bunch of goto statements (not 
necessarily within a function). Now...you've essentially no idea 
now which functions are truly encapsulated, and which aren't. You 
now have to take into view, 'the whole module' - which goes 
against the very principle of problem solving by breaking down 
the problem into smaller pieces.


I have looked a D source code modules. I challenge anyone to get 
there head around whole modules.


In a similar vain to gotos, having classes (which are 
traditionally meant to be encapsulated units of code) in a 
module, but also having anything in the module (outside of the 
class[es]), having the capacity to do whatever it wants to the 
private parts of the class.


We're back in goto land!

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Friday, 11 May 2018 at 12:59:21 UTC, Piotr Mitana wrote:
Might I suggest going back to the sealed classes topic? I don't 
think the discussion in this thread should go in the direction 
about the sense of using classes, proper encapsulation and the 
memory related stuff.


Actually, it is completely on topic. (although I understand that 
many on this forum are very eager to shut down any discussion 
about fixing class encapsulation in D, for some reason).


i.e, to be more specific.. so you can understand...my reply to 
'do I want sealed classes in D', is simply no. What I want first, 
is a class that can properly encapsulate itself.


Until that occurs, any talk about expanding the class concept 
with yet more attributes (that probably won't mean what you think 
they mean), like sealed, is just irrelevant and pushes the 
problem of broken encapsulation even further down peoples code 
paths.


private is not private at all in D, and because of this, classes 
are fundamentally broken in D (by design apparently).


Now.. I really do have better ways to spend my time. I've made my 
point. Nobody who uses D seems to think in a similar way, 
apparently, so I leave it at that.

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Friday, 11 May 2018 at 11:37:17 UTC, rikki cattermole wrote:


Well then, since you don't like how it is now, lets see the DIP.


it deserves to treated as a 'bug', not an DIP.

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Friday, 11 May 2018 at 10:43:19 UTC, rikki cattermole wrote:
Classes are expensive, not everybody wants to pay for what it 
gives in all situations.


Mmm...that claim is so broad is to be meaningless.

Good memory allocation algorithms, intelligent optimising 
compilers/runtimes, prudent use of class inheritance and other 
features, etc..etc all this can change performance one way or 
the other.


Programs that do not use classes can (very easily) become poor 
peforming too.


Anyway... nice way for you to sidetrack my argument ;-)
(which is about correcting, the incorrect implementation of class 
enscapsulation in D - so I can start using it).

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Friday, 11 May 2018 at 09:47:39 UTC, Dukc wrote:

On Friday, 11 May 2018 at 04:43:09 UTC, KingJoffrey wrote:

On Friday, 11 May 2018 at 03:32:25 UTC, Uknown wrote:


`private` is for outside the module. Within the module, 
private is not applied because D wanted to avoid C++'s 
`friend` functions.


'private' is "meant" to be part of the implementation of 'the 
class'.


Whereas D makes it part of the implementation of 'the module' 
( which is an even higher level of abstraction).


This is an abomination!

A class should have the capacity to protect its 
attributes/methods - even from the module.


You can use D private with Java-like "only for members 
functions" meaning by putting it alone in it's module, if you 
want.


Yes. I do know this. But that is essentially.. a hack.

A 'private' declaration should be part of the implementation of 
the class, not the class+module. Some say this is just a 
philosphical difference - I say it's a key design issue for 
structured programming.


A 'class' in D, should really be called a 'companion' (of the 
module), rather than a 'class', cause 'class' cannot truly 
implement it's own abstraction, but instead has its abstraction 
absorbed into the higher abstraction of the module.


So now, in D, to understand the class, you must also understand 
the module.


This is a backwards step in language design, in my opinion - for 
various reasons which are easy to examine further.


When I can contain the class abstraction within the class, then I 
will begin to take D more seriously.


Perhaps this is why some say 'idiomatic' D does not really use 
classes (cause they haven't been implemented correctly anyway, so 
why bother using them).

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Friday, 11 May 2018 at 05:10:08 UTC, Uknown wrote:

On Friday, 11 May 2018 at 04:43:09 UTC, KingJoffrey wrote:

On Friday, 11 May 2018 at 03:32:25 UTC, Uknown wrote:


`private` is for outside the module. Within the module, 
private is not applied because D wanted to avoid C++'s 
`friend` functions.


'private' is "meant" to be part of the implementation of 'the 
class'.


Whereas D makes it part of the implementation of 'the module' 
( which is an even higher level of abstraction).


This is an abomination!

A class should have the capacity to protect its 
attributes/methods - even from the module.


Let's not start this discussion again
https://forum.dlang.org/post/tksnoqntxtpgqbwsl...@forum.dlang.org


My point is, that adding sealed or anything else to classes, is a 
waste of time, cause a class is D, is not really a class at all.


A class in D, is some unprinciple pseudo-class, that cannot truly 
encapsulate itself any longer.

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Friday, 11 May 2018 at 03:32:25 UTC, Uknown wrote:


`private` is for outside the module. Within the module, private 
is not applied because D wanted to avoid C++'s `friend` 
functions.


'private' is "meant" to be part of the implementation of 'the 
class'.


Whereas D makes it part of the implementation of 'the module' ( 
which is an even higher level of abstraction).


This is an abomination!

A class should have the capacity to protect its 
attributes/methods - even from the module.

Re: auto: useful, annoying or bad practice?

[KingJoffrey via Digitalmars-d]

On Monday, 30 April 2018 at 21:11:07 UTC, Gerald wrote:


So I'm curious, what's the consensus on auto?


My rule, is when I can't be bothered typing it all out, or can't 
be bothered working out what it is I'm actually meant to type, 
then I use auto (or var).


i.e. I use it as a time saver, and that's all.

The exception to that rule, is when it's important to the person 
writing/reading that code, to known what type is being used (and 
that's a rather subjective decision). In most cases, the type 
declaration is for other reasons (i.e not human consumption).


btw. In 1969, John C. Reynolds published his paper/specification 
on GEDANKEN - a typeless programming language, and type 
declaration was simply not permitted.


(Gedanken is German for thought experiment, more or less)

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.492.9205=rep1=pdf

I wonder whether this is where languages will eventually end up 
again, in the future some time.

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Thursday, 10 May 2018 at 21:26:12 UTC, Jonathan M Davis wrote:

Idiomatic D tends to use classes rarely...


What is the basis for this assertion?

On a separate issue, 'private' should mean private! (not 
kinda-private).


Let's not make D classes even more of joke.