Re: Sealed classes - would you want them in D? (v2)
On Wednesday, 23 May 2018 at 02:23:31 UTC, Bjarne Stroustrup wrote: This is NOT why I created C++ - just so you programmers could violate an objects autonomy! So why did you create C++? On the serious side though, unencapsulated software is inflexible, and as a result, not very robust. The reason the class is more encapsulated than the struct is that more code might be broken if the (public) data members in the struct change than if the (private) data members of the class change. There is a direct relationship between encapsulation (how much code might be broken if something changes) and practical flexibility (the likelihood that we'll make a particular change). Now many of you may have heard my talks about 'Encapsulation and Non-Member Functions'. Let me remind you all though, that I was referring to non-member non-friend functions, not non-member functions that can penetrate your objects private parts. Penetration results in less encapsualtion, not more. So I support your Bjarne. Something need to be corrected in D.
Re: Sealed classes - would you want them in D? (v2)
On Wednesday, 23 May 2018 at 02:23:31 UTC, Bjarne Stroustrup wrote: This is NOT why I created C++ You are not Bjarne Stroustrup and you certainly did not created C++.
Re: Sealed classes - would you want them in D? (v2)
On Wednesday, 23 May 2018 at 02:23:31 UTC, Bjarne Stroustrup
wrote:
This is NOT why I created C++ - just so you programmers could
violate an objects autonomy!
No other type gets treated this way in D.
Good on you Bjarne. Someone has to stick up for the class.
We're with you Bjarne.
While you can't encapsulate a class in D anymore, you can at
least do this:
=
module test;
import std.stdio : writeln;
import std.range : iota;
void main()
{
writeln = iota = 5;
}
=
The software of the future is doomed!
Re: Sealed classes - would you want them in D? (v2)
On Tuesday, 22 May 2018 at 13:33:12 UTC, 12345swordy wrote: On Tuesday, 22 May 2018 at 03:10:39 UTC, Bjarne Stroustrup wrote: Any debate about restoring the rights and autonomy of the class, should not be killed off. Any programming language that discriminates against the class, encourages class warfare, does not deserve to be called a programming langauge. Knock it off with the hyperbole language already, this is a programming language not a civil rights movement. Wow! there is a generation that just simply has no sense of humour any more. We really are doomed. I have a right to say, that D is a programming langauge that discriminates against the autonomy of the class. You have a right to disagree. How? By allowing anything to penentrates it's private parts. This is NOT why I created C++ - just so you programmers could violate an objects autonomy! No other type gets treated this way in D. You write a function - you have to pass parameters in, and the function body determines the output. You have an int - you can only do clear specified operations on it. Ohh.. but a class... well..it's not actually a type anymore, in D. D programmers need to move on, from just focusing on algorithms, and start thinking about architecture too, becaue a type that cannot encapsulate itself, is useless in software architecture. That's not hyperbole - that's a plain, simple fact of the evolution of software architecture. Get out of your tree's and see the real world.
Re: Sealed classes - would you want them in D? (v2)
On Tuesday, 22 May 2018 at 13:33:12 UTC, 12345swordy wrote: On Tuesday, 22 May 2018 at 03:10:39 UTC, Bjarne Stroustrup wrote: Any debate about restoring the rights and autonomy of the class, should not be killed off. Any programming language that discriminates against the class, encourages class warfare, does not deserve to be called a programming langauge. Knock it off with the hyperbole language already, this is a programming language not a civil rights movement. The guy is unstable and has gone careening off since I kicked his soapbox... i mean his argument to pieces.
Re: Sealed classes - would you want them in D? (v2)
On Tuesday, 22 May 2018 at 03:10:39 UTC, Bjarne Stroustrup wrote: Any debate about restoring the rights and autonomy of the class, should not be killed off. Any programming language that discriminates against the class, encourages class warfare, does not deserve to be called a programming langauge. Knock it off with the hyperbole language already, this is a programming language not a civil rights movement.
Re: Sealed classes - would you want them in D? (v2)
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)
On Tuesday, 22 May 2018 at 07:34:24 UTC, bauss wrote: I cannot take you seriously when all you do is spread misinformation and invalid statistics. Don't under-estimate, the power of misinformation and invalid statistics. After all, if both can help you become supreme leader of the worlds foremost superpower, then, maybe they can also convince people to make 'the class' a protected species, and save it from extinction.
Re: Sealed classes - would you want them in D? (v2)
On Monday, 21 May 2018 at 03:19:34 UTC, KingJoffrey wrote: 18+ years, and still less than 1000 programmers. What kind of misinformation is that? vibe.d alone has over 2000 downloads per week and I'll mind you that regular users of vibe.d does not download or update the package that often. That means a large percentage of those are either new people trying out vibe.d. And most people programming in D do not even do web related programming or uses vibe.d, so in that sense the amount of people using D is WAY MORE than the amount of people weekly using vibe.d. Put that into perspective. I cannot take you seriously when all you do is spread misinformation and invalid statistics.
Re: Sealed classes - would you want them in D? (v2)
On Tuesday, 22 May 2018 at 03:10:39 UTC, Bjarne Stroustrup wrote: Any debate about restoring the rights and autonomy of the class, should not be killed off. Any programming language that discriminates against the class, encourages class warfare, does not deserve to be called a programming langauge. Let the debate continuedon't further disempower those advocating for the rights of the class. Don't worry class, some of us will always stand up to those that wish to destroy you. (ohh... is that what 'destroy' means... now I get it Andrei). I agree with my close, long time friend, Bjarne. Private access specifiers are used intentionally, in conjunction with carefully designed public method implementationsm, to enforce class invariants—constraints on the state of objects. As langauges continue towards relaxing, and even 'destroying' these constraints, the class will become an extinct species. And yet, the class/object model has proven to be a very powerful and unifying concept. If we destroy the class, we destroy the very core of not just the class, but also ourselves. For that matter, if we destroy the interface of the function, we end up in the same disastrous situation. i.e pointers! god help us all, cause nobody else can! Please, let's not destroy the autonomy of the object. We are ourselves, objects, afterall.
Re: Sealed classes - would you want them in D? (v2)
On Monday, 21 May 2018 at 19:51:38 UTC, Andrei Alexandrescu wrote: Hi folks, it looks like at least a few branches of this thread have run well past their useful course and into tedious territory. We don't like to go about killing threads, so we kindly ask that you all refrain from posting in this thread going forward. Thanks much! Andrei Andrei. Any debate about restoring the rights and autonomy of the class, should not be killed off. Any programming language that discriminates against the class, encourages class warfare, does not deserve to be called a programming langauge. Let the debate continuedon't further disempower those advocating for the rights of the class. Don't worry class, some of us will always stand up to those that wish to destroy you. (ohh... is that what 'destroy' means... now I get it Andrei).
Re: Sealed classes - would you want them in D? (v2)
On Monday, 21 May 2018 at 19:51:38 UTC, Andrei Alexandrescu wrote: Hi folks, it looks like at least a few branches of this thread have run well past their useful course and into tedious territory. We don't like to go about killing threads, so we kindly ask that you all refrain from posting in this thread going forward. Thanks much! Andrei wtf! That's the whole reason Dave got involved in this discussion - to kill it off. You've just empowered people like Dave. Well done Andrei.
Re: Sealed classes - would you want them in D? (v2)
Hi folks, it looks like at least a few branches of this thread have run well past their useful course and into tedious territory. We don't like to go about killing threads, so we kindly ask that you all refrain from posting in this thread going forward. Thanks much! Andrei
Re: Sealed classes - would you want them in D? (v2)
On Monday, 21 May 2018 at 15:30:40 UTC, Gheorghe Gabriel wrote: On Monday, 21 May 2018 at 15:07:39 UTC, KingJoffrey wrote: My suggestions are about resolving this, in order to attract more programmers to D, because I doubt I'm the only person in the world, that believes an object has a right to privacy. Of course you are not the only person that believes that. To have full private access in module scope is like you live in a building and there are no walls between apartments. If you put multiple classes in a single module, yeah it feels like it, that why people here recommend one class per module.
Re: Sealed classes - would you want them in D? (v2)
On Monday, 21 May 2018 at 16:35:57 UTC, rikki cattermole wrote: Please stop replying Dave, it isn't worth it. Do something more productive with your time :) I know, but... it helps me relax. ;-)
Re: Sealed classes - would you want them in D? (v2)
Please stop replying Dave, it isn't worth it. Do something more productive with your time :)
Re: Sealed classes - would you want them in D? (v2)
On Monday, 21 May 2018 at 14:54:57 UTC, KingJoffrey wrote: On Monday, 21 May 2018 at 14:46:40 UTC, Sjoerd Nijboer wrote: Also, I would verry much much like it if you would not resort to comparing me to "one of those facebook employees." It's just setting a mood for the conversation which no one likes, regardless what anyone thinks about facebook employees. people are so touchy here You want to have your cake and eat it, you want to be immature and label and denigrate people but you also want to be taken seriously. But you're too far up your own class to see it.
Re: Sealed classes - would you want them in D? (v2)
On Monday, 21 May 2018 at 09:56:22 UTC, KingJoffrey wrote: On Monday, 21 May 2018 at 09:16:42 UTC, Dave Jones wrote: da dah dah da dah dah dahh da d .. . ... da dah.. ..da.. da ...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. And yet again when he cant argue the point he sticks his fingers in his ears and starts shouting "la la la I cant hear you" like a spoilt little child. Well done Joffers.
Re: Sealed classes - would you want them in D? (v2)
On Monday, 21 May 2018 at 15:07:39 UTC, KingJoffrey wrote: My suggestions are about resolving this, in order to attract more programmers to D, because I doubt I'm the only person in the world, that believes an object has a right to privacy. Of course you are not the only person that believes that. To have full private access in module scope is like you live in a building and there are no walls between apartments.
Re: Sealed classes - would you want them in D? (v2)
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)
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)
On Monday, 21 May 2018 at 14:30:21 UTC, KingJoffrey wrote: On Monday, 21 May 2018 at 13:39:12 UTC, Sjoerd Nijboer wrote: While you might say that a unittest shouldn't acces private members and only public members, there are plenty of testcases where one would want to write a unittest to set a given variable via public function and then test if the appropriate private fields are properly set. While this sounds like a trivial usecase I believe it to be a verry big one in practice since it removes a lot of boilerplate code from your unit-tests, together with exposing the innards of a class's implementation to the outside world just so you can unit-test it. I have to ask, why isn't that unittest your talking about, within the scope of the class? Why is it outside the class, testing private innards of the class? I have trouble getting my head around this. This hypotetical unittest is testing a hypotetical class in a hypotetical module with hypotetical properties. Why is it outside the class? I don't know, maybe it needs access to two classes which are defined in thesame module. But also out of personal preference, I don't like random unittest declarations inside my class. Regardless, I think it's important for unittests to be able to do this. The last point is something I don't like about OOP + TDD in 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? 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. But besides that, I just wanted to put forward that we don't need to do `private(this)` or `private(className)` if this ever became a language feature because it would be confusing as to why it could bind to class or struct scope but not to any other scope and might as well introduce a new keyword which isn't regularly used in other languages like `sealed` but could instead come up with a new one. I felt that my response was incomplete whitout adding I think that the concept of a class private in D would not be a good idea. Also, I would verry much much like it if you would not resort to comparing me to "one of those facebook employees." It's just setting a mood for the conversation which no one likes, regardless what anyone thinks about facebook employees.
Re: Sealed classes - would you want them in D? (v2)
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)
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)
On Monday, 21 May 2018 at 09:56:22 UTC, KingJoffrey wrote: On Monday, 21 May 2018 at 09:16:42 UTC, Dave Jones wrote: da dah dah da dah dah dahh da d .. . ... da dah.. ..da.. da ...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. If you resort to mockery, then that means you have lost the argument.
Re: Sealed classes - would you want them in D? (v2)
On Friday, 18 May 2018 at 15:57:06 UTC, bachmeier wrote:
class A {
private int x;
private(this) int y;
}
Instead of such a syntax if this ever comes to be, we could just
introduce a new keyword into the language.
class A {
private int x;
closed int y; //closed for acces outside this class.
owned int z; //owned by this class.
inside int zz; //only accessible inside this class.
}
As far as I can tell we don't need a `private(this)` or
`private(classname)` declaration. I'd much rather have a keyword
specifically designed for the thing that it does.
D is at the point that there's already legacy code so you can't
use the `private` keyword anymore whitout doing something funky
with defining it private to class scope any other given scope. It
would also raise the question of "Why can't I have
`private(functionName)`? Does that make sense?"
I do see how this could be usefull if you had a 6000 line static
function that you don't want to have access to a private member
that is defined in thesame module. But then again, one could
simply extract it to its own module, reference the former module
and use those classes.
I personally find having no class private members incredibly
usefull since I can use them for unittests that way.
Then I can enforce the existance of a class member regardless of
its scope to exist and therefore enforce the use of a given
approach to the problem a class is solving.
While you might say that a unittest shouldn't acces private
members and only public members, there are plenty of testcases
where one would want to write a unittest to set a given variable
via public function and then test if the appropriate private
fields are properly set. While this sounds like a trivial usecase
I believe it to be a verry big one in practice since it removes a
lot of boilerplate code from your unit-tests, together with
exposing the innards of a class's implementation to the outside
world just so you can unit-test it. The last point is something I
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.
Re: Sealed classes - would you want them in D? (v2)
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)
On Monday, 21 May 2018 at 03:19:34 UTC, KingJoffrey wrote: On Sunday, 20 May 2018 at 11:19:01 UTC, Dave Jones wrote: On Sunday, 20 May 2018 at 02:45:25 UTC, KingJoffrey wrote: On Saturday, 19 May 2018 at 17:38:48 UTC, Gheorghe Gabriel wrote: Anyway... feel free to misrepresent what I've said, engage in hyperbole, snip the parts you cant argue with, speak for all the people who chose not to use D, tell D it's doomed if they don't do what you say, it'll never be popular, that it's all idiotic. Etc... Come on Dave. 18+ years, and still less than 1000 programmers. Do you have a citation for that? I have no idea how many users there are tbh. As I've said, I can have more that one class in a file in a variety of different mainstream languages, which represent about 20 million developers, and still have the compiler protect that interface from abuse, including accidental misuse. Delphi had the exact same thing and was probably the second largest IDE/Development platform on Windows for a very long time. The idea that it is a make or break feature is a figment of your imagination. You cannot get this in D, and yet 20 million developers have had this for decades. 20 million developers have had the friend feature for decades, it didn't stop Java becoming huge without it. The point is you constantly make logical fallacies of that sort... A has feature B and A is popular so it follows that to be popular you must implement B. And if I was taking your tone and attitude in pointing this out I would call that idiotic and by implication would be calling you an idiot. I'm not by the way, I'm being mature for once :) and just pointing it out without labelling you. When they come over to D, their' told, stuff you, we don't do it that way in D, and btw, we don't care about your ideas on how we could easily get D to do it both ways. We prefer our own way, so you get stuffed. Many people have engaged with you on your ideas. But lets be honest why should they care about your ideas when you clearly dont care about what they are saying? You have your position that "private means private" and that is the end of it. Nothing anyone can say will change your mind about that. That's why it's pointless, why talking to you is pointless. And you quickly resort to being derogatory when you dont get your own way, for example "LOL less than 1000 users after 15 years". Stuff like that. And you want to be taken seriously? BTW this is a user newsgroup it's not the steering group or the boardroom. Why on earth would you think you can change the direction of the language by shouting loudly in the local boozer? That's kind of what I've hearing from the D community. People pointing out flaws in your argument, saying this is what you have to do to get your ideas accepted and these are the kind of issues you will have to overcome, is not telling you to get stuffed. The problem is you dont seem to handle people disagreeing with you very well, you take it personally, that's why you resort to hyperbole and misrepresenting their position. You react emotionally instead of calm honest assessment of the facts. If people say "but D works for me, I like this feature" you say it's idiotic and a sign of small language mentality. Of course, that kind of attitude can only invite the same attitude back to the D community. Go back and read over both threads, people weren't rude to you. They basically said "huh works for me" and "takes a lot to get a change accepted". Let's hope you truly don't represent the D community, cause then my comments are not hyperbole, they are fact. I have very little to do with anything here tbh, i just tinker in D, dont have time for much more than that.
Re: Sealed classes - would you want them in D? (v2)
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)
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: Sealed classes - would you want them in D? (v2)
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...
Re: Sealed classes - would you want them in D? (v2)
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)
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)
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)
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.
Re: Sealed classes - would you want them in D? (v2)
On Saturday, 19 May 2018 at 04:01:18 UTC, KingJoffrey wrote:
On Friday, 18 May 2018 at 16:24:24 UTC, Gheorghe Gabriel wrote:
On Friday, 18 May 2018 at 15:57:06 UTC, bachmeier wrote:
On Friday, 18 May 2018 at 15:40:52 UTC, KingJo
class A {
private int x;
private(this) int y;
}
I agree that this looks a bit strange.
My initial proposal was "sealed" instead "private(this)" today.
Mmm.. that brings me back to the idea of sealed at the class
level again.
class A
{
private int x;
private(this) int y; // imagine if you have lots of private
variables.
// this could become pretty anoying -
and kinda redundant.
}
class A
{
private int x;
sealed int y; // again, what if you have lots of private
variables that
// that you really want sealed.
}
// Now. Back to the idea of sealed.
// abosolute consistency of your private variables.
// no redundancy.
// no some 'private', some 'sealed' confusion.
// no some 'private' (but really public) some 'private(this) ..
confusion.
//
sealed class A{
private int x;
private int y;
}
downside, is adding a new keyword, and getting agreement on
what that new keyword should be.
So I've come full circle again, and believe my idea is worth
further consideration.
If you have
sealed class A {
private {
// members
}
}
Then you can't use the defualt 'private' if you need it for a
specific member.
But if sealed is an access type of a member, 99% you will use
sealed insted private in a class, so it is not redundant.
class A {
sealed {
// members
}
private int friendMember;
}
And you use private keyword only if you need to access that
variable from a class/function/struct.. in the same module, like
a friend.
Re: Sealed classes - would you want them in D? (v2)
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?
Re: Sealed classes - would you want them in D? (v2)
On Saturday, 19 May 2018 at 04:01:18 UTC, KingJoffrey wrote:
Mmm.. that brings me back to the idea of sealed at the class
level again.
class A
{
private int x;
private(this) int y; // imagine if you have lots of private
variables.
// this could become pretty anoying -
and kinda redundant.
}
All attributes in D work the same way. You can write things like:
class A
{
@Jsonize:
private:
int a;
string b;
protected
{
long c;
}
@safe:
void privateSafeFunction() {}
void otherPrivateSafeFunction() {}
}
Perhaps you should learn more about the language before proposing
specific changes?
Re: Sealed classes - would you want them in D? (v2)
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)
On Saturday, 19 May 2018 at 09:10:32 UTC, KingJoffrey wrote: On Saturday, 19 May 2018 at 08:32:28 UTC, Uknown wrote: I ported your example to Java. Surprisingly, it compiled and executed just fine: All I see, is a class, with static members. How else would it work? This is the equivalent of my D example, in Java: ( it won't even compile. phew! ) The point was encapsulation as you defined it was broken. private members were directly modified outside their class. In your words, everyone was a friend.
Re: Sealed classes - would you want them in D? (v2)
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)
On Saturday, 19 May 2018 at 07:57:39 UTC, KingJoffrey wrote:
On Saturday, 19 May 2018 at 04:01:18 UTC, KingJoffrey wrote:
[...]
module test;
@safeinterface class Dog
{
private string noiseType = "woof";
public string makeNoise()
{
return this.noiseType;
}
}
void main()
{
import std.stdio;
auto dog = new Dog;
dog.noiseType = "meow"; // no way jose - requires use of
the safe interface!
writeln(dog.makeNoise()); // phew! cause dogs can only bark.
}
---
I ported your example to Java. Surprisingly, it compiled and
executed just fine:
--- test.java
class test
{
static class Dog
{
private String noiseType = "woof";
public String makeNoise()
{
return this.noiseType;
}
}
public static void main(String[] args)
{
Dog dog = new Dog();
dog.noiseType = "meow"; // no way jose - requires use of the
safe interface!
System.out.println(dog.makeNoise()); // phew! cause dogs meow.
}
}
---
Re: Sealed classes - would you want them in D? (v2)
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)
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)
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)
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)
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)
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)
On Friday, 18 May 2018 at 20:30:21 UTC, Dave Jones wrote: On Friday, 18 May 2018 at 18:12:55 UTC, Chris M. wrote: On Friday, 18 May 2018 at 17:59:04 UTC, Dave Jones wrote: On Friday, 18 May 2018 at 15:40:52 UTC, KingJoffrey wrote: On Friday, 18 May 2018 at 14:32:33 UTC, bachmeier wrote: It will attract more programmers, not less - and trust me, D better get more programmers using it, cause 18 years on, and it hasn't got that far, really. "Ohh Arya you will never be a lady if you keep walking around in your underclothes, even if it is just inside our chambers. You'll never have any friends or be popular, no one will ask you to the ball. You'll never be a lady." Ohh the drama... Let's just stop this part of the convo since it's clearly not going to bring us anywhere So lets stop the pointless gentle mockery and concentrate solely on the pointless. Sounds like a plan! The only thing that's going to drive this discussion forward is a few example use-cases (potentially borrowed from other languages that ran into similar 'problems'). I am new to D myself and how private works did surprise me but using the module/package method seems elegant enough to me.
Re: Sealed classes - would you want them in D? (v2)
On Friday, 18 May 2018 at 18:12:55 UTC, Chris M. wrote: On Friday, 18 May 2018 at 17:59:04 UTC, Dave Jones wrote: On Friday, 18 May 2018 at 15:40:52 UTC, KingJoffrey wrote: On Friday, 18 May 2018 at 14:32:33 UTC, bachmeier wrote: It will attract more programmers, not less - and trust me, D better get more programmers using it, cause 18 years on, and it hasn't got that far, really. "Ohh Arya you will never be a lady if you keep walking around in your underclothes, even if it is just inside our chambers. You'll never have any friends or be popular, no one will ask you to the ball. You'll never be a lady." Ohh the drama... Let's just stop this part of the convo since it's clearly not going to bring us anywhere So lets stop the pointless gentle mockery and concentrate solely on the pointless. Sounds like a plan!
Re: Sealed classes - would you want them in D? (v2)
On Friday, 18 May 2018 at 17:59:04 UTC, Dave Jones wrote: On Friday, 18 May 2018 at 15:40:52 UTC, KingJoffrey wrote: On Friday, 18 May 2018 at 14:32:33 UTC, bachmeier wrote: It will attract more programmers, not less - and trust me, D better get more programmers using it, cause 18 years on, and it hasn't got that far, really. "Ohh Arya you will never be a lady if you keep walking around in your underclothes, even if it is just inside our chambers. You'll never have any friends or be popular, no one will ask you to the ball. You'll never be a lady." Ohh the drama... Let's just stop this part of the convo since it's clearly not going to bring us anywhere
Re: Sealed classes - would you want them in D? (v2)
On Friday, 18 May 2018 at 15:40:52 UTC, KingJoffrey wrote: On Friday, 18 May 2018 at 14:32:33 UTC, bachmeier wrote: It will attract more programmers, not less - and trust me, D better get more programmers using it, cause 18 years on, and it hasn't got that far, really. "Ohh Arya you will never be a lady if you keep walking around in your underclothes, even if it is just inside our chambers. You'll never have any friends or be popular, no one will ask you to the ball. You'll never be a lady." Ohh the drama...
Re: Sealed classes - would you want them in D? (v2)
On Friday, 18 May 2018 at 11:41:33 UTC, KingJoffrey wrote: On Friday, 18 May 2018 at 09:07:57 UTC, Dave Jones wrote: FFS you're so dramatic. First the world is ending because private doesnt work as you expected. Then D is utterly useless without the changes you want. Now we live in some dystopian nightmare where we are all slaves to the Dlang spec. [..dadadadada...] Thanks Dave. You're welcome Joffers. You make my case (i.e. The D community is too small, and insufficiently diverse to discuss this any further.) You just reinforce the case that you have a tendency to drama and hyperbole. Except, that I'd add to that, that far too many are pretty immature too. I'd rather be pretty and immature than young and stupid. Good luck with your dlang thing...18+ years old and still < 1000 programmers (perhaps a lot less). (and if you have more than one class in a file, you have no more encapsulation - I love it). Oh here we go again... if people don't genuflect to Joffer's kingly wisdom he storms out like a pouty little tyrant muttering "good luck with your crappy language.. hhmmmppff idiots"
Re: Sealed classes - would you want them in D? (v2)
On 5/18/18 12:07 PM, Gheorghe Gabriel wrote:
Sometimes, I really need to put 2-3 or more different classes in a
module and I don't want them to share private members (friend classes).
The current solution is to create an individual module for each class,
but I don't like it when my class logic-strucrure fits better in the
same module. A better solution could be private(this). I am sure that D
really needs something like this. I have been talking with my friend
programmers for 4 hours and they don't like the fact that D classes
couldn't protect thier members in the same module. So they stuck on java
and c#..
You can "simulate" this by putting the classes into their own submodules
of the same package.
I.e. you want:
module mod;
class C {
private int _x;
int x() { return _x; }
}
void foo(C c)
{
auto x = c._x; // Oops, this should be an error
}
You can do this via:
mod/priv.d:
module mod.priv; // name however you like
class C { ... }
mod/package.d:
module mod;
public import mod.priv; // name isn't really important here
void foo(C c)
{
auto x = c._x; // Truly an error
}
user.d:
import mod; // imports both foo and C as if they were both in the same
module
-Steve
Re: Sealed classes - would you want them in D? (v2)
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.
Re: Sealed classes - would you want them in D? (v2)
On Friday, 18 May 2018 at 15:40:52 UTC, KingJoffrey wrote: On Friday, 18 May 2018 at 14:32:33 UTC, bachmeier wrote: [...] This is simply unavoidable - and, that 'surprise' you mention, is already there - it's not dependent on, or in any way related, to any proposal that might result from this discussion. The D 'private is really public in a module' concept, is here to stay (sadly, but it's true). [...] C++ is a complex beast, as a result of both needing to accomodate change (evolve), and not wanting to break backwards compatability. It's still *the* most powerful and flexible tool available for programmers. Beginner programmers would do well to keep that in mind. A class is just an abstract type, a tool for those that think it is useful in the solution for their problem domain. In any case, this discussion is not about convincing you of the value of classes - you should already know that if you are programmer. This discussion (at least my reason for being involved in it) is about breaking this idiotic (in my opinion) concept that D enforces on 'everyone' - i.e the one class per module, or everything is public, and you have no say in it. I don't necessarily object to the freedom the D module provides (i.e to bypass your interfaces, even accidently). What I object to is the 'i.e the one class per module, or everything is public, and you have no say in it.' A proposal that empowers the programmer to use the module for more than just a container for single class, coupled with static compile time verification - i.e you can't accidently access your private(this) T as it would be a compile time error, would be good for D (in my opinion), because those that have enjoyed having this capability in other mainstream langauges for literally decades!, won't be shut out from using D. It will attract more programmers, not less - and trust me, D better get more programmers using it, cause 18 years on, and it hasn't got that far, really. To get more programmers, you might want to be more open to accomodating their needs too. Although I do wonder, sometimes, whether the aim if D is just to be this cosy little langauge that not many use, except for those that do. Sometimes, I really need to put 2-3 or more different classes in a module and I don't want them to share private members (friend classes). The current solution is to create an individual module for each class, but I don't like it when my class logic-strucrure fits better in the same module. A better solution could be private(this). I am sure that D really needs something like this. I have been talking with my friend programmers for 4 hours and they don't like the fact that D classes couldn't protect thier members in the same module. So they stuck on java and c#..
Re: Sealed classes - would you want them in D? (v2)
On Friday, 18 May 2018 at 15:40:52 UTC, KingJoffrey wrote:
This discussion (at least my reason for being involved in it)
is about breaking this idiotic (in my opinion) concept that D
enforces on 'everyone' - i.e the one class per module, or
everything is public, and you have no say in it.
I don't necessarily object to the freedom the D module provides
(i.e to bypass your interfaces, even accidently). What I object
to is the 'i.e the one class per module, or everything is
public, and you have no say in it.'
I'm not saying I oppose making this change, but "evolution of the
language" takes the form of adding features but never eliminating
any. If I see
class A {
private int x;
private(this) int y;
}
it kind of makes my head hurt, and I've been using D for five
years. The justification I've seen for complications like private
vs public is that it's necessary for large programs. There's
something wrong if a single module is considered large.
Unlike most of the people that post here, I work with beginning
programmers. In almost all cases, decisions are made on the basis
of appeal to 20-year C++ veterans, but at least I can say I
raised the issue.
Re: Sealed classes - would you want them in D? (v2)
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)
On Friday, 18 May 2018 at 12:26:14 UTC, Gheorghe Gabriel wrote:
Good idea. Or: private(this)
Because using "this" it is easier tu put this code in a mixin
for multiple classes.
Example:
string var = "private(this) var;";
class A {
mixin(var);
}
class B {
mixin(var);
}
As clean and uncontroversial as this proposal might be, it
unfortunately doesn't resolve the biggest issue. If you try to
write Java code in D, you're still going to be using private, and
you're still going to be caught by surprise. And this is another
step in the direction of C++ (we need to think of beginning
programmers every so often) so there are costs. It's possible
that since I rarely use classes I'm not seeing the large benefits.
Re: Sealed classes - would you want them in D? (v2)
On Friday, 18 May 2018 at 12:42:05 UTC, KingJoffrey wrote:
How hard is it to convince people, that being able to have the
compiler detect semantic errors that break your defined
interface is actually a good thing. I mean really. I've had
this capability in major languages for decades.
Let D empower the programmer in this case, by giving that back
to them (as an opt-in)
Two points:
1) the status quo in D is not generally viewed as a violation of
encapsulation (if you change the class, you can also change the
module)
2) there's a simple workaround already in place for people who
really, really, want to do it
The DIP will need to provide counters to both of these points.
One example for point one off the top of my head --
Currently, if you do something like change the name of a private
member, anything in the module still referencing the old symbol
will cause a compiler error and you can fix it immediately.
But, say you have this code:
```
class Foo {
private int _x;
int x { return _x; }
}
void printFoo(Foo f) { writeln("Foo: ", f._x);
```
And later, you decide you want to track all accesses to _x in a
foo instance:
```
class Foo {
private int _x;
private int _xHits;
int x() {
++_xHits;
return _x;
}
// Oops!
void printFoo(Foo f) { writeln("Foo: ", f._x);
```
This would only manifest itself at runtime and in a large module
could be one of those bugs that keeps you scratching your head
for much longer than it ought to. The same thing can happen
through accessing _x internally in the class, but the surface
area is smaller and the bug could (theoretically) be caught more
quickly (and preventing even this is the rationale behind the
Java style of using accessors internally).
So that's the sort of thing a DIP would need to be doing.
Essentially, answering the questions: what are the holes in the
status quo ("encapsulation is violated" doesn't cut it -- solid
examples of real issues are required), and how is the proposed
solution superior to the workaround?
Re: Sealed classes - would you want them in D? (v2)
On Friday, 18 May 2018 at 12:16:55 UTC, aliak wrote:
You may not need a new word at all. You can also enhance
private to take arguments. Package already does this. You can
give private a symbol list that says which symbols this is
private for. So:
class A {
private int x;
private(A) int y;
}
void main() {
A a = new A();
a.x = 7; // ok, it's private to module
a.y = 3; // error, it's sealed to class
}
Cheers,
- Ali
Don't really have a stake in the convo, but I'll jump in to say
this looks like a solid solution to me (also agree 'this' instead
of classname).
Re: Sealed classes - would you want them in D? (v2)
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)
On Friday, 18 May 2018 at 12:32:30 UTC, Mike Parker wrote:
private(this) int y;
This keeps the implementation simple and the scope focused.
Yeah, maybe more focused at the beginning would be better. A
comma separated list can be added later if deemed worthy.
And agreed, the java recommendation might help build a case.
There's also the argument of avoiding state related bugs in
larger code bases that is managed through computed properties:
class A {
@property int i() {
// fix internal state due to access
return _i;
}
private int _i;
}
Of course these are all solved by putting a class in its own
module anyway. I can see this being problematic the bigger code
bases get though. I.e. programmer A adds an extension function in
module M that is 6000 lines long and doesn't see that he should
do A.i and not A._i - bug maybe goes unnoticed for long time.
Only thing I can actually think of is if you want to have
extension functions on classes in the same module and only want
some variables to be accessible from extension functions but keep
other truly private, you can't do this. So it makes writing code
in an extension based style harder. But then you can argue if an
extension needs to access private(this) variables then it should
be module private anyway. So meh...
Re: Sealed classes - would you want them in D? (v2)
On 5/17/18 10:08 PM, KingJoffrey wrote: On Thursday, 17 May 2018 at 14:14:28 UTC, Steven Schveighoffer wrote: D's main draw is not OOP. So if you are here for OOP goodies, then you are definitely better off looking elsewhere. I'll add that too my list of D forum quotes. Awesome, I love being on lists! That being said, D does have OOP, and many OOP programmers are fine with the current state of affairs. How many OOP programmers in the world? Too many. How many of them use D? Only the good ones ;) Your use of the word 'many' is questionable. Many means more than a few. Not disputing that, it's a reasonable choice either way. And yet, the D community is intent on not empowering the programmer to make that choice themselves. I'm not aware of a programming language that lets the user decide what keywords are supposed to mean. If there is one, let me know so I can stay away. Unfortunately, that fails the first time you see code that has "sealed" on it, and have to go figure out what exactly that means. That's what happend to me, with the 'D version' of 'private'. It happened to me too! https://forum.dlang.org/post/fbs28v$2ss6$1...@digitalmars.com And then I learned how it worked and said "oh, ok, makes sense". You can say the same for every other attribute D has, that I had never seen before. It's a nonsense argument that many use, to prevent change. The argument is that it *does* add to the load needed to understand the language, so it better be worth it. It's not a nonsense argument, every extra attribute adds extra cognitive load. So saying the change would be "blind" to those people who don't care about it is not true. When you see an attribute that you don't understand, you need to look it up to see what it does, it may do something you don't want it to. You're welcome to write a DIP, but I don't see a very good chance for acceptance given the discussions on this subject. I agree. The D community is too small, and insufficiently diverse to discuss this any further. Hm.. I see you are still here arguing though. Interesting. It's funny how we build programming languages to serve us, but we end up serving them. This should go on your quotes list I think. Or maybe a fortune cookie. -Steve
Re: Sealed classes - would you want them in D? (v2)
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)
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)
On Friday, 18 May 2018 at 12:26:14 UTC, Gheorghe Gabriel wrote:
Good idea. Or: private(this)
Because using "this" it is easier tu put this code in a mixin
for multiple classes.
Example:
string var = "private(this) var;";
class A {
mixin(var);
}
class B {
mixin(var);
}
Me like :)
You can have both so you can do what you say with private(this)
and also allow access from other classes/structs
class A { private(this, B) onlyForMeAndTypeB; }
Essentially a more fine grained version of C++'s friend.
Re: Sealed classes - would you want them in D? (v2)
On Friday, 18 May 2018 at 12:16:55 UTC, aliak wrote:
You may not need a new word at all. You can also enhance
private to take arguments. Package already does this. You can
give private a symbol list that says which symbols this is
private for. So:
class A {
private int x;
private(A) int y;
}
void main() {
A a = new A();
a.x = 7; // ok, it's private to module
a.y = 3; // error, it's sealed to class
}
That's actually a decent way to go about it. It matches the
package syntax and avoids new keywords. It's also not as onerous
as repurposing an existing keyword (like `module`), nor does it
cause any breakage. Though, I would argue that rather than
allowing any old symbol, it be restricted to `this`:
private(this) int y;
This keeps the implementation simple and the scope focused. If a
DIP were put forward, I think this would be the approach to take.
Though a fairly strong case will still need to be made as to why
this is beneficial (use cases, example code, etc). To bolster the
case, I would look at the reasoning behind the recommendation in
Java that classes use the public API internally rather than
manipulating member variables directly to improve maintainability.
Re: Sealed classes - would you want them in D? (v2)
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)
On Friday, 18 May 2018 at 12:16:55 UTC, aliak wrote:
On Friday, 18 May 2018 at 12:00:58 UTC, Gheorghe Gabriel wrote:
On Thursday, 17 May 2018 at 02:32:07 UTC, KingJoffrey wrote:
[...]
I think this code has cleaner sintax:
class A {
private int x;
sealed int y;
}
void main() {
A a = new A();
a.x = 7; // ok, it's private to module
a.y = 3; // error, it's sealed to class
}
You may not need a new word at all. You can also enhance
private to take arguments. Package already does this. You can
give private a symbol list that says which symbols this is
private for. So:
class A {
private int x;
private(A) int y;
}
void main() {
A a = new A();
a.x = 7; // ok, it's private to module
a.y = 3; // error, it's sealed to class
}
Cheers,
- Ali
Good idea. Or: private(this)
Because using "this" it is easier tu put this code in a mixin for
multiple classes.
Example:
string var = "private(this) var;";
class A {
mixin(var);
}
class B {
mixin(var);
}
Re: Sealed classes - would you want them in D? (v2)
On Friday, 18 May 2018 at 12:00:58 UTC, Gheorghe Gabriel wrote:
On Thursday, 17 May 2018 at 02:32:07 UTC, KingJoffrey wrote:
I propose an idea, for discussion (robust discussion even
better ;-)
Add an new attribute to class, named 'sealed'.
No, not sealed as in Scala.
No, not sealed as in C#
sealed as in oxford dictionary (close securely, non-porous).
when sealed is applied on the class, this means the class is
sealed.
the sealed attribute only makes sense within a module, and
affects nothing outside of the module.
When sealed is applied to the class, then, interfacing to a
class within a module, from code outside that class - but
still within the module, can now only occur via the published
interface of the class.
outside code in the module, can no longer directly access your
private parts!
The class is sealed.
I think this code has cleaner sintax:
class A {
private int x;
sealed int y;
}
void main() {
A a = new A();
a.x = 7; // ok, it's private to module
a.y = 3; // error, it's sealed to class
}
You may not need a new word at all. You can also enhance private
to take arguments. Package already does this. You can give
private a symbol list that says which symbols this is private
for. So:
class A {
private int x;
private(A) int y;
}
void main() {
A a = new A();
a.x = 7; // ok, it's private to module
a.y = 3; // error, it's sealed to class
}
Cheers,
- Ali
Re: Sealed classes - would you want them in D? (v2)
On Thursday, 17 May 2018 at 02:32:07 UTC, KingJoffrey wrote:
I propose an idea, for discussion (robust discussion even
better ;-)
Add an new attribute to class, named 'sealed'.
No, not sealed as in Scala.
No, not sealed as in C#
sealed as in oxford dictionary (close securely, non-porous).
when sealed is applied on the class, this means the class is
sealed.
the sealed attribute only makes sense within a module, and
affects nothing outside of the module.
When sealed is applied to the class, then, interfacing to a
class within a module, from code outside that class - but still
within the module, can now only occur via the published
interface of the class.
outside code in the module, can no longer directly access your
private parts!
The class is sealed.
I think this code has cleaner sintax:
class A {
private int x;
sealed int y;
}
void main() {
A a = new A();
a.x = 7; // ok, it's private to module
a.y = 3; // error, it's sealed to class
}
Re: Sealed classes - would you want them in D? (v2)
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)
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)
On Friday, 18 May 2018 at 02:08:47 UTC, KingJoffrey wrote: On Thursday, 17 May 2018 at 14:14:28 UTC, Steven Schveighoffer wrote: You're welcome to write a DIP, but I don't see a very good chance for acceptance given the discussions on this subject. -Steve I agree. The D community is too small, and insufficiently diverse to discuss this any further. It's funny how we build programming languages to serve us, but we end up serving them. FFS you're so dramatic. First the world is ending because private doesnt work as you expected. Then D is utterly useless without the changes you want. Now we live in some dystopian nightmare where we are all slaves to the Dlang spec. Listen up dude, people here have been using D as it is, are happy with how it works, and even prefer how it works. They have done so for months or years. That is a big bar for you to get over, they have years of experience with D working for them. Coming in and saying "ooh but thats wrong, your doing it wrong.. because OOP... etc..." waving your arms, making hyperbolic statements about how its the end of the world etc... wont win any arguments. You cant convince people of what you say if all you do is give them an ideological*** argument that is counter to their years of experience. That's just the way it is, it's actually better that way, because otherwise people would be swayed by every passing preacher and everything would be in a right mess. ***Your argument is ideological because you dont provide any evidence for it. This has been pointed out and yet you still dont seem grasp it. Saying "this is what you need to do and this is why it will benefit" is not evidence, it is a statement of belief. Please understand I am not saying what you want is right or wrong, I'm saying you dont understand why people aren't won over by what you say.
Re: Sealed classes - would you want them in D? (v2)
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)
On Thursday, 17 May 2018 at 07:58:55 UTC, KingJoffrey wrote: Remember, the idea for discussion is about adding one single attribute 'sealed' to the class - the discussion is a lot less about 'how can we prevent having to add a this new attribute'. It is normal, whenever someone suggests changing the language, to talk about alternatives that don't involve changing the language. We can't properly discuss how important a change is without going through the existing ways to solve the problem. If I proposed a change, or if Walter or Andrei did, we'd have the same sorts of discussion. Do you think you should be exempt?
Re: Sealed classes - would you want them in D? (v2)
On 5/17/18 9:38 AM, KingJoffrey wrote: On Thursday, 17 May 2018 at 13:28:19 UTC, Steven Schveighoffer wrote: Essentially, if you put your class you want "sealed" into it's own module, and then publicly import the module from the API module, you will get the same effect. This is even easier now with the package module than it used to be. Fair enough. Now no OOP programmer has any need to take at look at D. I can already do that in other, better known, better supported languages. D's main draw is not OOP. So if you are here for OOP goodies, then you are definitely better off looking elsewhere. That being said, D does have OOP, and many OOP programmers are fine with the current state of affairs. What private currently does is rational and makes sense. It's not the same as all other languages, but it is the same as some of them. It's simply a preference, and D picked something different from what you like. There are things I would have picked differently than D also, but not much to be done about those choices at this point. The other persepective is also rational, and makes sense. Not disputing that, it's a reasonable choice either way. I believe both perspectives could be accomodated, and at the same time without breaking anything, and without affecting in any way, the way people currently use the module. The change would be completely blind to those people, until they choose to opt in to the change. Unfortunately, that fails the first time you see code that has "sealed" on it, and have to go figure out what exactly that means. If D is at the point where change can no longer occured, it's over for D. That's not what was stated. This proposal is a convenience feature, because you can already accomplish what is requested (making sure private internals are inaccessible to certain parts of the code). At this point, making incremental changes like this requires a very high bar of acceptance since you would be adding another complication to a language that is fairly stable. If I were you, I would stop worrying about this and either accept the status quo or look for a language that suits your requirements more directly. I think there are probably no people here who think D is the "perfect language", or that there even exists a "perfect language", you just have to judge whether the warts are worth living with or not. You're welcome to write a DIP, but I don't see a very good chance for acceptance given the discussions on this subject. -Steve
Re: Sealed classes - would you want them in D? (v2)
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)
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)
On 5/16/18 10:32 PM, KingJoffrey wrote: I propose an idea, for discussion (robust discussion even better ;-) Add an new attribute to class, named 'sealed'. No, not sealed as in Scala. No, not sealed as in C# sealed as in oxford dictionary (close securely, non-porous). when sealed is applied on the class, this means the class is sealed. the sealed attribute only makes sense within a module, and affects nothing outside of the module. When sealed is applied to the class, then, interfacing to a class within a module, from code outside that class - but still within the module, can now only occur via the published interface of the class. outside code in the module, can no longer directly access your private parts! The class is sealed. I don't think you are going to get this to fly. We already have abilities to make the details truly private. I agree it's not as straightforward as other languages, but it is possible. Lately, the chances of adding an enhancement like this is pretty slim -- we have a mechanism to do it already, but is just a little more clunky. And it's not a huge problem for most code. I'd predict that if this were to be accepted, it would seldom be used anyway. So the cost/benefit ratio is very high. Essentially, if you put your class you want "sealed" into it's own module, and then publicly import the module from the API module, you will get the same effect. This is even easier now with the package module than it used to be. What private currently does is rational and makes sense. It's not the same as all other languages, but it is the same as some of them. It's simply a preference, and D picked something different from what you like. There are things I would have picked differently than D also, but not much to be done about those choices at this point. -Steve
Re: Sealed classes - would you want them in D? (v2)
On Thursday, 17 May 2018 at 11:18:52 UTC, KingJoffrey wrote:
On Thursday, 17 May 2018 at 10:34:18 UTC, Zoadian wrote:
On Thursday, 17 May 2018 at 02:32:07 UTC, KingJoffrey wrote:
[...]
People from c++ might be suprised by 'private' already. We do
not have to confuse those c#ies too.
Interesting.
If only D had applied that same criteria to use of the word
'private'.
Have you considered the keyword `module`?
--- kings.d
class King
{
private string _name;
module string __name;
public string getName()
{
return __name;
}
public void setName(string name)
{
__name = name;
}
}
void main()
{
scope king = new King();
king._name = "me"; //ok: _name is private
king.__name = "me"; //error: __name is of `module` scope
king.setName("me"); //ok
}
I do wonder what word could possibly suffice, to please
everyone.
`module`
/s
[...]
Again, DIP before discussion, and we all know what will happed
to the DIP.
I won't oppose such an addition since it will be purely opt-in,
but you will have to consider that this would add more specifiers:
`private`, `protected`, `package`, `public` and `export`.
You might also want to read these [0] past discussions on this
feature. I'm not sure how up to date that doc is, but it should
be a good starting point.
[0]:
https://wiki.dlang.org/Access_specifiers_and_visibility#Current_state_of_affairs_in_C.2B.2B
Re: Sealed classes - would you want them in D? (v2)
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)
On Thursday, 17 May 2018 at 02:32:07 UTC, KingJoffrey wrote: I propose an idea, for discussion (robust discussion even better ;-) Add an new attribute to class, named 'sealed'. No, not sealed as in Scala. No, not sealed as in C# sealed as in oxford dictionary (close securely, non-porous). when sealed is applied on the class, this means the class is sealed. the sealed attribute only makes sense within a module, and affects nothing outside of the module. When sealed is applied to the class, then, interfacing to a class within a module, from code outside that class - but still within the module, can now only occur via the published interface of the class. outside code in the module, can no longer directly access your private parts! The class is sealed. I don't think that "sealed" is the right name here. Currently C# has its sealed and Scala has its sealed - and these are different things (although I don't code C# and may be wrong, it seems like C#'s sealed is Java's or D's final). I believe that giving "sealed" keyword yet another sense in D is not the right approach. Furthermore, I don't believe that the proposed version of sealed would be a widely-used feature that broadens the language capabilities. It solves the problem that - as discussion in my thread shown - some people consider valid, and some not. My opinion is that it's not worth a new keyword and time for implementing. In the same manner you could ask for removing friend concept from C++ as a bad concept. I don't answer the question whether this concept is good or bad - just give an example. The difference is that you can just go without friend at all, and module-level private is forced. The other reason I don't think it is a feature significant enough is kind of library level. I expect that only author or limited team of people will freely modify the code of module. So there is limited number of people that have a control over the module and it shouldn't be a big deal not to refer to private fields outside the class or define it as a team rule. I believe that a nice approach here would be to add a check to DScanner, so that your editor or IDE could optionally warn you if you refer to the private member from outside the class. But as module is a small unit and its code should probably be controlled/verified by the limited number of people, I don't see this as a big deal. Note that Scala-like sealed from my proposal would have a greater impact (it blocks inheritance outside the module - helps to prevent the library code from being used in a way it is not designed to) and your proposal changes things in a very limited scope. OFC, I am not a "compiler person", nor Walter, Andrei and anyone from the team, so my opinion is definitely not decisive in any way :) To sum up [TLDR]: I don't see your arguments strong enough to alter the language (especially make a cross-language confusion over the "sealed" keyword), but DScaner check would still allow to track down what you consider bad.
Re: Sealed classes - would you want them in D? (v2)
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)
On Thursday, 17 May 2018 at 02:32:07 UTC, KingJoffrey wrote: I propose an idea, for discussion (robust discussion even better ;-) Add an new attribute to class, named 'sealed'. If class level protection is added, please do not call it sealed. People from c++ might be suprised by 'private' already. We do not have to confuse those c#ies too. Module level protection is enough to hide implementation details though. So while i do understand why you want this in D, i don't think it is worth it to complicate the language for something you can work around easily by putting the classes in their own modules. I'm also not convinced think that your 'sealed' would be used much, because accessing private state in the module is actually extremly useful (e.g. unittests). That beeing said, if you are convinced it would be a good addition, please write a DIP. Even if it will not be accepted it will at least force a decision. And we can point to the reasons it got accepted/rejected in the future.
Re: Sealed classes - would you want them in D? (v2)
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)
On Thursday, 17 May 2018 at 07:30:58 UTC, KingJoffrey wrote:
On Thursday, 17 May 2018 at 06:03:19 UTC, arturg wrote:
you could declare the public api of your class inside an
actual interface then use it instead of the class, that wont
give you access to the private members of the class.
you mean like this?
module test;
interface Animal { string makeNoise(); }
class Dog : Animal
{
private string noiseType = "woof";
override string makeNoise()
{
return this.noiseType;
}
}
void main()
{
import std.stdio;
auto dog = new Dog;
dog.noiseType = "meow"; // grr!
writeln(dog.makeNoise()); // wtf! Thanks to D, my dog can
now meow!
}
no, that uses type inferance.
you have to do
Animal dog = new Dog;
Re: Sealed classes - would you want them in D? (v2)
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)
On Thursday, 17 May 2018 at 05:06:54 UTC, KingJoffrey wrote: If people want to propose putting each class in it's own module, that does not address my requirements, and therefore is not helpful to this discussion. you could declare the public api of your class inside an actual interface then use it instead of the class, that wont give you access to the private members of the class.
Re: Sealed classes - would you want them in D? (v2)
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)
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)
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)
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)
Can you provide even one anecdote where this would have been useful and the workaround that has been suggested to you multiple times (putting the type in its own module) wouldn't have worked or would have caused other problems? I mean, usually we need to do a cost/benefit analysis, and the first part of that, the one that people generally do instinctively, is try to describe the benefit. You seem to view the benefit as self-evident, but we've told you many times that it isn't self-evident to us, so you have more work to do if you want to convince anyone. If you just want to vent, though, you might say that explicitly.
Re: Sealed classes - would you want them in D? (v2)
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)
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.
