Re: Non-ugly ways to implement a 'static' class or namespace?
On Monday, 20 February 2023 at 07:11:49 UTC, Mike Parker wrote: On Monday, 20 February 2023 at 06:26:34 UTC, FeepingCreature wrote: There have now been three pages produced by three people all agreeing with each other. At what point does it start being spam? Yes, it's all just noise now. Let's end it here. Further posts in this thread will be deleted. oy vey, shut it down fucking idiot
Re: Non-ugly ways to implement a 'static' class or namespace?
On Monday, 20 February 2023 at 06:26:34 UTC, FeepingCreature wrote: There have now been three pages produced by three people all agreeing with each other. At what point does it start being spam? Yes, it's all just noise now. Let's end it here. Further posts in this thread will be deleted.
Re: Non-ugly ways to implement a 'static' class or namespace?
But in any case, it should be class private. There have now been three pages produced by three people all agreeing with each other. At what point does it start being spam? Having a discussion !== spam.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Monday, 20 February 2023 at 05:21:44 UTC, forky wrote: On Friday, 10 February 2023 at 07:04:31 UTC, Max Samukha wrote: ... Having class-private doesn't preclude module-private. Dennis even submitted a PR implementing class-private, but it stalled because people couldn't agree on whether class-private should be "private to class" or "private to class instance". It likely the 'disagreement' was intentional .. i.e. to stall ;-) But in any case, it should be class private. There have now been three pages produced by three people all agreeing with each other. At what point does it start being spam?
Re: Non-ugly ways to implement a 'static' class or namespace?
On Friday, 10 February 2023 at 07:04:31 UTC, Max Samukha wrote: ... Having class-private doesn't preclude module-private. Dennis even submitted a PR implementing class-private, but it stalled because people couldn't agree on whether class-private should be "private to class" or "private to class instance". It likely the 'disagreement' was intentional .. i.e. to stall ;-) But in any case, it should be class private.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Sunday, 19 February 2023 at 00:21:42 UTC, ProtectAndHide wrote: On Saturday, 18 February 2023 at 21:23:24 UTC, ProtectAndHide wrote: The more I look at D, the more I like C++. I should correct that. The more I look at D, the more I like C++, C#, Java, Kotlin, Swift, Javascript .. and the list goes on.. All D needed to provide, was a way to let the programmer declare a private member inside a class. But that is too much for the language to handle, and so objectionable to many D users, that it will never happen. I have no problem with that, because, i really do have many other options - as do all the C++, C#, Java, Kotlin, Swift, Javascript .. and the list goes on..that you supposedly want to attract to D (although, I suspect nobody actually wants to attract them, since they'll expect to be able to declare a private member within a class. So.. good luck with the .. ummm.. D thing. Even if D did have the private feature, the ecosystem and community is too small for this language to be a viable option. Also D is not used on the job market, so good luck finding a D job.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Sunday, 19 February 2023 at 00:21:42 UTC, ProtectAndHide wrote: On Saturday, 18 February 2023 at 21:23:24 UTC, ProtectAndHide wrote: The more I look at D, the more I like C++. I should correct that. The more I look at D, the more I like C++, C#, Java, Kotlin, Swift, Javascript .. and the list goes on.. All D needed to provide, was a way to let the programmer declare a private member inside a class. But that is too much for the language to handle, and so objectionable to many D users, that it will never happen. I have no problem with that, because, i really do have many other options - as do all the C++, C#, Java, Kotlin, Swift, Javascript .. and the list goes on..that you supposedly want to attract to D (although, I suspect nobody actually wants to attract them, since they'll expect to be able to declare a private member within a class. So.. good luck with the .. ummm.. D thing. Based. I've already switched to TypeScript, Java, etc. Goodbye D.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Saturday, 18 February 2023 at 21:23:24 UTC, ProtectAndHide wrote: The more I look at D, the more I like C++. I should correct that. The more I look at D, the more I like C++, C#, Java, Kotlin, Swift, Javascript .. and the list goes on.. All D needed to provide, was a way to let the programmer declare a private member inside a class. But that is too much for the language to handle, and so objectionable to many D users, that it will never happen. I have no problem with that, because, i really do have many other options - as do all the C++, C#, Java, Kotlin, Swift, Javascript .. and the list goes on..that you supposedly want to attract to D (although, I suspect nobody actually wants to attract them, since they'll expect to be able to declare a private member within a class. So.. good luck with the .. ummm.. D thing.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Saturday, 18 February 2023 at 22:03:48 UTC, Adam D Ruppe wrote: On Saturday, 18 February 2023 at 21:23:24 UTC, ProtectAndHide wrote: The more I look at D, the more I like C++. cya of course, I do have my own fork ;-) where you CAN declare private members for your class. and.. where all the importC nonsense, does not even exist in the compiler. it's not public.. because I prefer private.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Saturday, 18 February 2023 at 22:03:48 UTC, Adam D Ruppe wrote: On Saturday, 18 February 2023 at 21:23:24 UTC, ProtectAndHide wrote: The more I look at D, the more I like C++. cya I bet that's what you say to anyone who dares want to have hidden members inside their class. All the threads are public and on record ;-)
Re: Non-ugly ways to implement a 'static' class or namespace?
On Saturday, 18 February 2023 at 21:23:24 UTC, ProtectAndHide wrote: The more I look at D, the more I like C++. cya
Re: Non-ugly ways to implement a 'static' class or namespace?
On Saturday, 18 February 2023 at 21:23:24 UTC, ProtectAndHide
wrote:
Here is (one example) of the change I would like to see in D:
if private is declared against a member inside a class (or
struct), then that member is visible only inside that class or
struct. That is what most programmers in the world would expect.
(most, not all).
if you want open access to that class, from other code in the
same module, you mark that class (or struct) as open.
e.g
class foo
{
private int x; // visible in this class only
}
open class bar
{
private int y; // visible throughout the module - the same as it
currently works.
}
so all you'd have to do, is mark your class (or struct) as open,
and then anyone reading your code will immediately know that
other code in the module may form part of the specification of
this class.
so simple.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Saturday, 18 February 2023 at 07:49:03 UTC, RTM wrote: On Saturday, 18 February 2023 at 06:55:49 UTC, ProtectAndHide wrote: More likely is comes from my experience .. otherwise I wouldn't be surprised ;-) Now that's a screaming sign: https://media.licdn.com/dms/image/C4D12AQEymZALzWVDXQ/article-cover_image-shrink_600_2000/0/1629008577928?e=2147483647&v=beta&t=yBj1ft4wivYyPzpwtwlYFlBpvw_PwSgNqx_ixFIGcOM No, I think D is not for me. Implying that D language maintainers should prefer your personal taste over modern practice? Don't like it, don't use it. The more I look at D, the more I like C++.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Saturday, 18 February 2023 at 07:49:03 UTC, RTM wrote: Implying that D language maintainers should prefer your personal taste over modern practice? So it's now modern practice to dump the principle of data hiding? I'm sure that will surely advance the science of programming. Don't like it, don't use it. On this we can agree. D has an ongoing, and ever-getting-stronger love affair with C. So for OO programmers, I'd argue there are far better languages available - ones that provide the tools to make OOP easier, rather than harder, and give programmers choice over their design, instead of forcing a design upon them. A language that claims to support OOP using classes, but provides no language mechanism to the programmer so they can explicately hide members, but rather ***INSISTS*** that all class members be wide open to use by all other code in the module, is just a joke - IMO. Better for D to stop making that claim, and remove classes from the language.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Saturday, 18 February 2023 at 06:55:49 UTC, ProtectAndHide wrote: More likely is comes from my experience .. otherwise I wouldn't be surprised ;-) Now that's a screaming sign: https://media.licdn.com/dms/image/C4D12AQEymZALzWVDXQ/article-cover_image-shrink_600_2000/0/1629008577928?e=2147483647&v=beta&t=yBj1ft4wivYyPzpwtwlYFlBpvw_PwSgNqx_ixFIGcOM No, I think D is not for me. Implying that D language maintainers should prefer your personal taste over modern practice? Don't like it, don't use it.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Saturday, 18 February 2023 at 06:55:49 UTC, ProtectAndHide wrote: No, I think D is not for me. They don't care about the needs of `D` users! They won't listen ,even if you said it thousand times.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Saturday, 18 February 2023 at 06:12:47 UTC, RTM wrote:
No offense, but it looks like your surprise comes from your
inexperience.
More likely is comes from my experience .. otherwise I wouldn't
be surprised ;-)
btw.
I love the way that Brayan Martinez (Senior Developer with Azure,
Spring Boot, and Flutter.) outlines all the well-thoughout out
positive reasons.
https://github.com/dart-lang/sdk/issues/33383#issuecomment-395987115
Then the next guy says..."Sounds like personal preference."
https://github.com/dart-lang/sdk/issues/33383#issuecomment-396031405
As for me, I don't even know what Dart is ;-)
I guess we could all revert to:
class foo()
{
int _x; // this is private. please don't use it outside of this
class.
}
and hope that people read and comply with that instruction -
cause we all know how great people are at following instructions
;-)
D could just add a new keyword (problem solved!)
class foo()
{
intern int x; // x is internal to foo.
}
of course, then we get to the next issue ... protected ;-)
No, I think D is not for me.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Friday, 17 February 2023 at 22:58:19 UTC, ProtectAndHide wrote: Actually, I just now understand 'why' (as opposed to 'how') private works in D the way it does. In D, private within a module is (more-or-less) like static used in C outside of a function. That is, in C it restrains the visibility to the current file, and so it does in D (visibility to the current module). ok fine. That works well in C. But C does not have classes! (user defined types with their own abstraction boundaries). So what would happen if C got classes then? Well, we already know -> C++ (private declared within a user-defined type, restrains visibility to that type). And so it does in C#, Java, Swift, Javascript .. ... So in essence, the D module is still stuck in the C era it seems. Now I'm fully convinced that OOP should never, ever, ever, be done in D. Now I can finally move on ;-)
Re: Non-ugly ways to implement a 'static' class or namespace?
On Friday, 17 February 2023 at 04:58:17 UTC, RTM wrote: Data hiding is overrated. ... Actually, data hiding is at the core of using objects, and objects are at the core of doing OOP. " Hiding internal state and requiring all interaction to be performed through an object's methods is known as data encapsulation — a fundamental principle of object-oriented programming." https://docs.oracle.com/javase/tutorial/java/concepts/object.html D can 'provide' that encapsulation. That is true. But it does it **indirectly**, by requiring the class representing that object to not have any other code in the module containing that class. If there is any other code in the module with that class (including unittests), then that class is no longer encapsulated. There should be no argument as to whether the statements above are correct or not. They are clearly correct. The only objection people can reasonably raise, is whether its ok to provide encapsulation in this manner (i.e. indirectly), or whether the language should provide a mechanism whereby the progammer can 'declare' the encapsulation. It should not come as a surprise, given C++, C#, Java, Swift, Javascript.. .. ... that a programmer might want to have more explicit access control... since they have it in those languages ... and those languages represent the vast majority of the worlds programmers. What is surprising, is the level of objection in the D community to allow such an option in D. Since the majority of programmers in the world HAVE this option already, there will be continued debate over this issue, should they ever come and have a look at D. That much is certain. But the debate should not be about whether a programmer needs to encapsulate their object. That is a choice the programmer should make. It's a design decision for them, not for others. The debate should be whether those programmers should be FORCED to put each and every class in its own modules. That's a design being forced on the programmer in order to get encapsulation of that object. D forces a 1:1 mapping of class to module in order to provide object encapsulation. That is what I don't like. Keep in mind, this also means unittests must be in a separate module as well, as the unittest in the same module as the class, means the class is no longer encapsulated (i.e. the compiler cannot assist you - in relation to type safety - when you accidently reference a private member - which is what I did when I first came to D - and hence, is the reason for my raising this as an issue in the first place). I think this thread has lost any usefulness, because many try redirect the issue at hand to something else completely. But this post summarises the problem well enough for everyone to understand - and choose their side ;-)
Re: Non-ugly ways to implement a 'static' class or namespace?
On Friday, 17 February 2023 at 09:56:26 UTC, RTM wrote: On Friday, 17 February 2023 at 06:56:08 UTC, ProtectAndHide Thirty years passed since. Lessons were learned. Out of three PLs of the newer generation (Rust, Swift, Go), two are not OOP, basically. And no private/public/protected: https://doc.rust-lang.org/reference/keywords.html https://go.dev/ref/spec#Keywords :-P this is not a discussion about one paradigm or language being better or worse than another. btw. neither Rust nor Go claim to support OOP. They don't even have a class type. so it doesn't suprise me they don't have a language mechanism for class-type privacy. for OOP using classes, the class designer should be able to expose only that which should be exposed, and no more. in D, everything is exposed inside the module, and the only solution D provides to prevent this, is to not put any other code in the same module as that class - this includes not putting your unittests in that module either. please compare apples with apples, not apples with sardines ;-)
Re: Non-ugly ways to implement a 'static' class or namespace?
Funny, seems I have old news: Rust adopted D-like module visibility. https://doc.rust-lang.org/reference/visibility-and-privacy.html pub(in path), pub(crate), pub(super), and pub(self) In addition to public and private, Rust allows users to declare an item as visible only within a given scope. The rules for pub restrictions are as follows: pub(in path) makes an item visible within the provided path. path must be an ancestor module of the item whose visibility is being declared. pub(crate) makes an item visible within the current crate. pub(super) makes an item visible to the parent module. This is equivalent to pub(in super). pub(self) makes an item visible to the current module. This is equivalent to pub(in self) or not using pub at all.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Friday, 17 February 2023 at 06:56:08 UTC, ProtectAndHide wrote: What is 'Object-Oriented Programming'? (1991 revised version) Bjarne Stroustrup https://www.stroustrup.com/whatis.pdf Thirty years passed since. Lessons were learned. Out of three PLs of the newer generation (Rust, Swift, Go), two are not OOP, basically. And no private/public/protected: https://doc.rust-lang.org/reference/keywords.html https://go.dev/ref/spec#Keywords :-P
Re: Non-ugly ways to implement a 'static' class or namespace?
On Friday, 17 February 2023 at 04:58:17 UTC, RTM wrote: Data hiding is overrated. Furthermore, OOP is overrated :-) https://betterprogramming.pub/object-oriented-programming-the-trillion-dollar-disaster-92a4b666c7c7 What is 'Object-Oriented Programming'? (1991 revised version) Bjarne Stroustrup https://www.stroustrup.com/whatis.pdf
Re: Non-ugly ways to implement a 'static' class or namespace?
On Friday, 17 February 2023 at 04:58:17 UTC, RTM wrote: Data hiding is overrated. Furthermore, OOP is overrated :-) https://betterprogramming.pub/object-oriented-programming-the-trillion-dollar-disaster-92a4b666c7c7 Submit a request to the C++ Committee to remove private from the language. Do the same for C# Do the same for Swift Do the same for Javasript... Then watch how they all ridicule you for presenting such an absurd proposal ;-) Oddly enough, then you will know how I feel when I'm ridiculed for advocating that D adds a private-like declaration for the type - something all those languages have, and the majority of the programmers in those languages would be using on a regular basis. As for OOP being overrated, I don't necessarily disagree ;-) But OOP is a tool that works well, when that tool is the best tool for the job.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Friday, 17 February 2023 at 04:43:11 UTC, RTM wrote: On Thursday, 16 February 2023 at 20:56:00 UTC, ProtectAndHide wrote: Both the module type, and the class type need this capability. No, they are not. Look at Go. Go does not have classes.
Re: Non-ugly ways to implement a 'static' class or namespace?
Data hiding is overrated. Furthermore, OOP is overrated :-) https://betterprogramming.pub/object-oriented-programming-the-trillion-dollar-disaster-92a4b666c7c7
Re: Non-ugly ways to implement a 'static' class or namespace?
On Thursday, 16 February 2023 at 20:56:00 UTC, ProtectAndHide wrote: Both the module type, and the class type need this capability. No, they are not. Look at Go.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Friday, 17 February 2023 at 01:21:18 UTC, zjh wrote: They don't admit their mistakes! And `D` community is getting smaller and smaller! Because other languages laughs cry! `D` don't even have `type-safe` classes. The ability of a group of people to open their eyes and tell lies is really eye-opening.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Friday, 17 February 2023 at 01:13:59 UTC, zjh wrote: They can't refute you, so they have to blame you. You can't wake up who pretend to sleep. They don't admit their mistakes! And `D` community is getting smaller and smaller! If I were D author , I would suspect that they are undercover agents of other language communities! Because other languages laughs cry! `D` don't even have `type-safe` classes.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Thursday, 16 February 2023 at 22:25:22 UTC, ProtectAndHide wrote: also, I noticed that you intentionally? did not respond to the facts that I outlined: ie. They can't refute you, so they have to blame you. You can't wake up who pretend to sleep.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Thursday, 16 February 2023 at 21:56:03 UTC, bachmeier wrote: On Thursday, 16 February 2023 at 21:23:53 UTC, ProtectAndHide wrote: Forcing programmers to use a design mechanism rather than a language mechanism to achieve the above abstraction is wrong. This seems to be the source of the disagreement, correct? There's no disagreement. It's you posting the same false claim again and again (presumably because you're hoping it will come up when someone does a search for it, or some similar reason) and others explaining why you're wrong. If you don't want to use the language, don't use it. You have your subjective preferences. You are unable to muster a good argument in favor of it. There's no reason to (yet again) post the same thing over and over. also, I noticed that you intentionally? did not respond to the facts that I outlined: ie. Objects are data abstractions with an interface of named operations and a hidden local state. Does anyone disagree with this? D does not have a language mechanism, but rather a design mechanism that supports the above. By that I mean, you cannot use a language 'declaration' mechanism to enforce the above, but rather have to revert to a design mechanism - putting the class that represents that object into a module by itself. Does anyone disagrre with this? Forcing programmers to use a design mechanism rather than a language mechanism to achieve the above abstraction is wrong. This seems to be the source of the disagreement, correct? So some think its fine to force this onto programmers? That is essentially your argument... right? This is about the language. It's not personal. Don't make it personal!
Re: Non-ugly ways to implement a 'static' class or namespace?
On Thursday, 16 February 2023 at 21:56:03 UTC, bachmeier wrote: On Thursday, 16 February 2023 at 21:23:53 UTC, ProtectAndHide wrote: Forcing programmers to use a design mechanism rather than a language mechanism to achieve the above abstraction is wrong. This seems to be the source of the disagreement, correct? There's no disagreement. It's you posting the same false claim again and again (presumably because you're hoping it will come up when someone does a search for it, or some similar reason) and others explaining why you're wrong. If you don't want to use the language, don't use it. You have your subjective preferences. You are unable to muster a good argument in favor of it. There's no reason to (yet again) post the same thing over and over. It's your claim that is false. What I outlined is correct. I've even shown code that clearly demonatrates it. I don't know how you can call those claims false. They are fact. And any D programmers know what I've said is correct. The disagreement, is whether D should do something about it. Not that what I've demonstrated is incorrect. Also, I don't keep posting just cause I like to doing it. I'm responding to people like you who continually make accusations against me which are not correct. Try focusing on the source of the disagreement, and not on personal issues. Then we will not have this constant to and fro. Instead, we will end up disagreeing on some language design issue, and that will be that. Stop making it personal!
Re: Non-ugly ways to implement a 'static' class or namespace?
On Thursday, 16 February 2023 at 21:23:53 UTC, ProtectAndHide wrote: Forcing programmers to use a design mechanism rather than a language mechanism to achieve the above abstraction is wrong. This seems to be the source of the disagreement, correct? There's no disagreement. It's you posting the same false claim again and again (presumably because you're hoping it will come up when someone does a search for it, or some similar reason) and others explaining why you're wrong. If you don't want to use the language, don't use it. You have your subjective preferences. You are unable to muster a good argument in favor of it. There's no reason to (yet again) post the same thing over and over.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Thursday, 16 February 2023 at 20:56:00 UTC, ProtectAndHide wrote: My agrument is this: Objects are data abstractions with an interface of named operations and a hidden local state. Does anyone disagree with this? D does not have a language mechanism, but rather a design mechanism that supports the above. By that I mean, you cannot use a language 'declaration' mechanism to enforce the above, but rather have to revert to a design mechanism - putting the class that represents that object into a module by itself. Does anyone disagrre with this? Forcing programmers to use a design mechanism rather than a language mechanism to achieve the above abstraction is wrong. This seems to be the source of the disagreement, correct? So some think its fine to force this onto programmers? That is essentially your argument... right?
Re: Non-ugly ways to implement a 'static' class or namespace?
On Thursday, 16 February 2023 at 13:39:13 UTC, H. S. Teoh wrote: On Thu, Feb 16, 2023 at 08:51:39AM +, FeepingCreature via Digitalmars-d-learn wrote: [...] Springboarding off this post: This thread is vastly dominated by some people who care very much about this issue. Comparatively, for instance, I care very little because I think D already does it right. But then the thread will look unbalanced. This is a fundamental design flaw in forum software. So let me just say: I think D does it right. D does not have class encapsulation; it has module encapsulation. This is by design, and the design is good. +1, this issue is wayyy overblown by a vocal minority. D's design diverges from other languages, but that in itself does not make it a bad design. In the context of D it actually makes sense. Saying that D's design is bad because language X does it differently is logically fallacious (X is good, Y is not X, therefore Y is bad). T It's really the vocal majority that makes this issue overblown. One person saying they don't like something...dozens deciding to weigh in and say how wrong he is. So whose doing the overblowing? The 'fact' of the matter is, that the vast majority of programmers in the most major languages have the capacity to explicately declare hidden data associated with their user-defined type (class, struct..whatever). Both the module type, and the class type need this capability. One without the other leads to the kind of errors I made when I first started writing classes in D (which of course I now longer use D for). So for the D's 'majority' to flood this thread saying 'no we're right and you're wrong' and all the other major languages in the world are wrong, as are their designers, and all the programmers using them are blind, and don't really need that capability... I mean really? Are we meant to take that seriously? D was clearly created by procedural programmers for procedural programmers. And again, a language that deliberately forces an important design decision onto programmers (one-user-defined-type per module just to protect its hidden data), is wrong. D people saying its fine, are wrong. It's just wrong. If you think its not wrong, you are wrong. A user-defined type where the programmer cannot explicately declare protected hidden data, is wrong. If you think its not wrong, you are wrong.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Thu, Feb 16, 2023 at 08:51:39AM +, FeepingCreature via Digitalmars-d-learn wrote: [...] > Springboarding off this post: > > This thread is vastly dominated by some people who care very much > about this issue. Comparatively, for instance, I care very little > because I think D already does it right. > > But then the thread will look unbalanced. This is a fundamental design > flaw in forum software. > > So let me just say: I think D does it right. D does not have class > encapsulation; it has module encapsulation. This is by design, and the > design is good. +1, this issue is wayyy overblown by a vocal minority. D's design diverges from other languages, but that in itself does not make it a bad design. In the context of D it actually makes sense. Saying that D's design is bad because language X does it differently is logically fallacious (X is good, Y is not X, therefore Y is bad). T -- He who sacrifices functionality for ease of use, loses both and deserves neither. -- Slashdotter
Re: Non-ugly ways to implement a 'static' class or namespace?
So let me just say: I think D does it right. D does not have class encapsulation; it has module encapsulation. This is by design, and the design is good. The design is terrible...
Re: Non-ugly ways to implement a 'static' class or namespace?
On Thursday, 16 February 2023 at 02:27:23 UTC, Mike Parker wrote: On Thursday, 16 February 2023 at 02:26:44 UTC, Mike Parker wrote: Wrong. I'm arguing things: Geez. "I'm arguing 2 things:" Springboarding off this post: This thread is vastly dominated by some people who care very much about this issue. Comparatively, for instance, I care very little because I think D already does it right. But then the thread will look unbalanced. This is a fundamental design flaw in forum software. So let me just say: I think D does it right. D does not have class encapsulation; it has module encapsulation. This is by design, and the design is good.
Re: Non-ugly ways to implement a 'static' class or namespace?
But at stop mispresenting what I'm saying. What I've stated above, is what I'm saying.. no more.. no less. Well said. Its not that hard to understand, folks.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Wednesday, 15 February 2023 at 12:44:19 UTC, zjh wrote: Right... They greatly increase your code maintenance work! Many people left D because of these small details! Their encapsulation can actually leakage class members. Programmers in other languages will laugh cry!
Re: Non-ugly ways to implement a 'static' class or namespace?
On Thursday, 16 February 2023 at 02:56:28 UTC, ProtectAndHide wrote: What a joke. Even Javascript can do this (and the compile will enforce it too). https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes/Private_class_fields
Re: Non-ugly ways to implement a 'static' class or namespace?
On Thursday, 16 February 2023 at 02:26:44 UTC, Mike Parker wrote: On Wednesday, 15 February 2023 at 20:10:31 UTC, ProtectAndHide wrote: What Mike is arguing, is that I don't need a 'data hiding' mechanism for a user-defined type, because that is already provided to me by the 'data hiding' mechanism of the module. That is his argument. My argument is that I want 'data hiding' mechanism at the user-defined type level as well. Again, his argument is that i don't need it.. because... Wrong. I'm arguing things: 1. D has encapsulation (you say it doesn't). My code in my previous post should make it clear what I'm saying. Stop misrepresenting my argument. 2. We don't need a new protection attribute or a redefinition of private because D already provides the mechanism to give you what you want. First, who is 'we'? Likely the programmers that do need it, have decided to go elsewhere (where they can get it, and have likely had it, for decades - not in some obscure language, but in the most major languages being used.). Second, you don't provide what I want. You can keep saying that you do, but that doesn't change it. C++, C#, Swift, hell even Javascript.. they provide what I want. D does not. So don't say it does, until it does...and that day will come ;-)
Re: Non-ugly ways to implement a 'static' class or namespace?
On Thursday, 16 February 2023 at 02:26:44 UTC, Mike Parker wrote:
On Wednesday, 15 February 2023 at 20:10:31 UTC, ProtectAndHide
wrote:
What Mike is arguing, is that I don't need a 'data hiding'
mechanism for a user-defined type, because that is already
provided to me by the 'data hiding' mechanism of the module.
That is his argument.
My argument is that I want 'data hiding' mechanism at the
user-defined type level as well.
Again, his argument is that i don't need it.. because...
Wrong. I'm arguing things:
1. D has encapsulation (you say it doesn't).
2. We don't need a new protection attribute or a redefinition
of private because D already provides the mechanism to give you
what you want.
Honestly. How hard is it for you to accept? It's so simple I
could explain it to first year programmer!
It's really straight forward, obvious, correct, and can be
demonstrated like this:
// foo type has no ability (at the type level)
// to hide anything from other code in the module.
// this is fact. I'm not making it up!
// There is nothing to argue against here. It's just fact.
module test;
@safe:
import std;
class foo { private int x = 10; } // C++, C#, Swift,
Javascript...programmers - beware!
void main()
{
foo f = new foo;
f.x = 20; // D provides no way to prevent this from occuring
as there is no mechanism at the type level to do this. Instead
you have to put foo in a module by itself, so no other code can
access x. So EVERY user-defined type that wants data hiding from
users of that type (including other code in the module using that
type), must be in its own module.
writeln(f.x);
}
I understand your argument completely. Just put foo in its own
module. I get it.
What you don't get, is that I want such design decisions to be in
my hands, and not yours.
That is, I want a mechanism at the type level as well.
You don't want me to have that. Well fine.
But at stop mispresenting what I'm saying. What I've stated
above, is what I'm saying.. no more.. no less.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Thursday, 16 February 2023 at 02:26:44 UTC, Mike Parker wrote: Wrong. I'm arguing things: Geez. "I'm arguing 2 things:"
Re: Non-ugly ways to implement a 'static' class or namespace?
On Wednesday, 15 February 2023 at 20:10:31 UTC, ProtectAndHide wrote: What Mike is arguing, is that I don't need a 'data hiding' mechanism for a user-defined type, because that is already provided to me by the 'data hiding' mechanism of the module. That is his argument. My argument is that I want 'data hiding' mechanism at the user-defined type level as well. Again, his argument is that i don't need it.. because... Wrong. I'm arguing things: 1. D has encapsulation (you say it doesn't). 2. We don't need a new protection attribute or a redefinition of private because D already provides the mechanism to give you what you want.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Wednesday, 15 February 2023 at 20:34:13 UTC, thebluepandabear wrote: On Wednesday, 15 February 2023 at 20:06:18 UTC, bachmeier wrote: On Wednesday, 15 February 2023 at 07:13:41 UTC, thebluepandabear wrote: Time to move on to OCaml programmers telling us D doesn't have floating point arithmetic because there's no `+.` operator. that's not the same thing though, you've created a great false equivalence! Congrats. Only if you don't understand D's encapsulation. You're going on at length (apparently under multiple names in this thread) because you don't like D's implementation of encapsulation. That's no different from complaining that the `+` operator should be `+.`, and until D makes the change, it doesn't support floating point addition. There are reasonable arguments for changing and not changing D's implementation of encapsulation. Your claim that D doesn't support encapsulation is false. 'under multiple names'... You can clearly see I have the same name, simply different profile pictures. You should know by now, that anyone that supports the idea of D providing an explicit mechanism to support data hiding for a user-defined type, are all the **same** person. Nobody else in the world supports such an idea. It's all just one person... apparently ;-)
Re: Non-ugly ways to implement a 'static' class or namespace?
On Wednesday, 15 February 2023 at 20:06:18 UTC, bachmeier wrote: On Wednesday, 15 February 2023 at 07:13:41 UTC, thebluepandabear wrote: Time to move on to OCaml programmers telling us D doesn't have floating point arithmetic because there's no `+.` operator. that's not the same thing though, you've created a great false equivalence! Congrats. Only if you don't understand D's encapsulation. You're going on at length (apparently under multiple names in this thread) because you don't like D's implementation of encapsulation. That's no different from complaining that the `+` operator should be `+.`, and until D makes the change, it doesn't support floating point addition. There are reasonable arguments for changing and not changing D's implementation of encapsulation. Your claim that D doesn't support encapsulation is false. 'under multiple names'... You can clearly see I have the same name, simply different profile pictures.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Wednesday, 15 February 2023 at 20:10:31 UTC, ProtectAndHide wrote: ... this is not to be personal, just to make an analogy about the point being made: if Mike was a car salesperson, he'd be arguing that I don't need an automatic transmission. I can already do it manually. Why should we complicate our design by making an automatic tranmission if you can alreay change gears anyway. Well..do you think I'd end up buying my new car from him?
Re: Non-ugly ways to implement a 'static' class or namespace?
On Wednesday, 15 February 2023 at 20:01:12 UTC, bachmeier wrote: On Wednesday, 15 February 2023 at 19:44:50 UTC, ProtectAndHide wrote: A user-defined type is a type that has a mechanism to keep it representation private. D does not support this. It only enables it. You (and others) may well argue that D should not enable this (directly), it should only support it (indirectly), and thus allow the language to force an important design decision onto programmers. As a programmer, I don't think that is acceptable. The response was to your claim that "I think what you could say is that D lacks _encapsulation_ which is also an OOP concept. So D is partially OOP but not fully OOP due to there being no encapsulation in the language." Mike demonstrated clearly that your claim is false. My claims are factually correct. What Mike is arguing, is that I don't need a 'data hiding' mechanism for a user-defined type, because that is already provided to me by the 'data hiding' mechanism of the module. That is his argument. My argument is that I want 'data hiding' mechanism at the user-defined type level as well. Again, his argument is that i don't need it.. because... And my argument is, that I want it... And his arguement is, that I don't need it.. And... And. And...
Re: Non-ugly ways to implement a 'static' class or namespace?
On Wednesday, 15 February 2023 at 07:13:41 UTC, thebluepandabear wrote: Time to move on to OCaml programmers telling us D doesn't have floating point arithmetic because there's no `+.` operator. that's not the same thing though, you've created a great false equivalence! Congrats. Only if you don't understand D's encapsulation. You're going on at length (apparently under multiple names in this thread) because you don't like D's implementation of encapsulation. That's no different from complaining that the `+` operator should be `+.`, and until D makes the change, it doesn't support floating point addition. There are reasonable arguments for changing and not changing D's implementation of encapsulation. Your claim that D doesn't support encapsulation is false.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Wednesday, 15 February 2023 at 19:44:50 UTC, ProtectAndHide wrote: "The basic support for programming with data abstraction consists of facilities for defining a set of operations (functions and operators) for a type and for restricting the access to objects of the type to that set of operations." D does not enable this. It only supports it, because the programmer has to revert to 'data hiding techniques' at the module level, instead of at the type level. D should enable programmers to express and utilise 'proper' types, just as C++, C#, Swift can... hell, even Javascript enables programmers to do this. What is 'Object-Oriented Programming'? (1991 revised version) Bjarne Stroustrup https://www.stroustrup.com/whatis.pdf
Re: Non-ugly ways to implement a 'static' class or namespace?
On Wednesday, 15 February 2023 at 19:44:50 UTC, ProtectAndHide wrote: A user-defined type is a type that has a mechanism to keep it representation private. D does not support this. It only enables it. You (and others) may well argue that D should not enable this (directly), it should only support it (indirectly), and thus allow the language to force an important design decision onto programmers. As a programmer, I don't think that is acceptable. The response was to your claim that "I think what you could say is that D lacks _encapsulation_ which is also an OOP concept. So D is partially OOP but not fully OOP due to there being no encapsulation in the language." Mike demonstrated clearly that your claim is false.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Wednesday, 15 February 2023 at 10:17:30 UTC, Mike Parker wrote: I referenced that in my post. The exact same problem exists *inside* the class when your class file is very long. You can easily manipulate the private member even when it's only supposed to be accessed by a specific function. You're missing the point, completely. We're discussing the issue of type safety. Your talking about typing mistakes. .. in D: the private implementation is in the source file. The fact that the source file represents a module rather than a single class is irrelevant. Again, this is about type safety, supported by the compiler. Read that article by Stroustup that I cited, so you can obtain a clearer understanding what it is 'he' is saying, because what I am saying. In essence, he discusses how inferior a type created through a module mechanism is, compared to a user-defined type (and that user-defined types were provided by languages for that very reason). The key being, that user-defined types provide their own mechanism for data hiding (the representation is private). D's module system supports this, but it does not 'enable' it. i.e. it supports it by forcing the programmer to put that type into its own module. We keep repeating the same arguments over and over and over again on this.. That's because the key idea being presented here, is not being taken on board. A user-defined type is a type that has a mechanism to keep it representation private. D does not support this. It only enables it. You (and others) may well argue that D should not enable this (directly), it should only support it (indirectly), and thus allow the language to force an important design decision onto programmers. As a programmer, I don't think that is acceptable.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Wednesday, 15 February 2023 at 09:57:56 UTC, ProtectAndHide wrote: In a module that contains a class, and other code as well (perhaps other tightly coupled classes), you can know **nothing** at all about that type (or any other class) without knowing **everything** else in the module. If one understands this, then one understands the problem here ;-) .. btw. other code.. includes unitests as well. The solution that D provides, is not a solution. It's a design constraint being forced on programmers. Anyone that argues otherwise, is speaking out of their ... Right... They greatly increase your code maintenance work!
Re: Non-ugly ways to implement a 'static' class or namespace?
On Wednesday, 15 February 2023 at 08:56:00 UTC, Mike Parker wrote: Our friend of many forum handles misses no opportunity to return to this putrid horse corpse to beat it some more, but the meaning of private isn't going to change. This is D's approach to encapsulation. It seems the only beating go on here, is the beating your handing out. If someone raises a comment about type private, and you all jump in any beat on him, then who is the real victim here? Try to keep it about language design, and stop getting personal.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Wednesday, 15 February 2023 at 08:56:00 UTC, Mike Parker wrote: Our friend of many forum handles misses no opportunity to return to this putrid horse corpse to beat it some more, but the meaning of private isn't going to change. This is D's approach to encapsulation. It seems the only beating go on here, is the beating your handing out. If someone raises a comment about type private, and you all jump in any beat on him, then who is the real victim here? Try to keep it about language design, and stop getting personal.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Wednesday, 15 February 2023 at 10:17:30 UTC, Mike Parker wrote: We keep repeating the same arguments over and over and over again on this. I still haven't seen any convincing argument for changing things when it's already possible to do what you want to do. I repeat for the umpteenth time: if you care so much about who can touch your private parts, then put your classes and structs in their own modules and use D's package facilities to provide the public interface you want. The convincing arguement (convincing to me anyway) was made when I came to D, programmed a class, and put a unittest in the same module, and accidently referenced hidden data of my class in my unittest. This result in a bug. It was when i was tracking down the source of this bug, that I discovered that private is not private at all (inside the module). If there is a cycle continuing, it's because your solution to a 'real' problem (read above again please), is to force an unreasonable design constraint onto the programmer. This includes being forced to put your unittest in its own module as well (for reasons demonstrated above). It should be up to the programmer to decide what types should go into their module: Not the language! You think the language has this right to force such a constraint onto the programmer, I do not. That really is the basis for the disagreement here. I want fewer modules, each containing tighly couple types. You want more modules, each containing one single type. I want unittest in the same module as my type. You want me to have them in their own module as well. No. I cannot accept this as a reasonable solution.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Wednesday, 15 February 2023 at 10:17:30 UTC, Mike Parker wrote: I referenced that in my post. The exact same problem exists *inside* the class when your class file is very long. You can easily manipulate the private member even when it's only supposed to be accessed by a specific function. A common recommendation in Java used to be (and probably still is) to always accessing private members by their setters even inside the class. And after all these years they haven't had a need to lock down single-method access to private members. It's the *exact* same thing in D: the private implementation is in the source file. The fact that the source file represents a module rather than a single class is irrelevant. We keep repeating the same arguments over and over and over again on this. I still haven't seen any convincing argument for changing things when it's already possible to do what you want to do. I repeat for the umpteenth time: if you care so much about who can touch your private parts, then put your classes and structs in their own modules and use D's package facilities to provide the public interface you want. Class level private, which can ensure that there will never be any leakage and there will be no encapsulation misuse, At the module level, this is unavoidable! And there are closely related classes, which should be placed in a module.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Wednesday, 15 February 2023 at 09:51:41 UTC, zjh wrote: What if two classes in the module that are several meters apart make `mistakes` that change the privite variable of `another class`? No one can guarantee that after `a few months`, even if you are the author, you will not make mistakes, so as to misuse private variable, while `class level` private can be completely avoided it! There is no maintainability, because two `out-of-class` functions may quietly change your private `variables`. I referenced that in my post. The exact same problem exists *inside* the class when your class file is very long. You can easily manipulate the private member even when it's only supposed to be accessed by a specific function. A common recommendation in Java used to be (and probably still is) to always accessing private members by their setters even inside the class. And after all these years they haven't had a need to lock down single-method access to private members. It's the *exact* same thing in D: the private implementation is in the source file. The fact that the source file represents a module rather than a single class is irrelevant. We keep repeating the same arguments over and over and over again on this. I still haven't seen any convincing argument for changing things when it's already possible to do what you want to do. I repeat for the umpteenth time: if you care so much about who can touch your private parts, then put your classes and structs in their own modules and use D's package facilities to provide the public interface you want.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Wednesday, 15 February 2023 at 09:51:41 UTC, zjh wrote: On Wednesday, 15 February 2023 at 08:57:27 UTC, Mike Parker wrote: I meant to say, it "wouldn't add more". What if two classes in the module that are several meters apart make `mistakes` that change the privite variable of `another class`? No one can guarantee that after `a few months`, even if you are the author, you will not make mistakes, so as to misuse private variable, while `class level` private can be completely avoided it! There is no maintainability, because two `out-of-class` functions may quietly change your private `variables`. In a module that contains a class, and other code as well (perhaps other tightly coupled classes), you can know **nothing** at all about that type (or any other class) without knowing **everything** else in the module. If one understands this, then one understands the problem here ;-) .. btw. other code.. includes unitests as well. The solution that D provides, is not a solution. It's a design constraint being forced on programmers. Anyone that argues otherwise, is speaking out of their ...
Re: Non-ugly ways to implement a 'static' class or namespace?
On Wednesday, 15 February 2023 at 07:23:39 UTC, thebluepandabear wrote: On Wednesday, 15 February 2023 at 02:14:30 UTC, Mike Parker wrote: On Wednesday, 15 February 2023 at 01:16:00 UTC, thebluepandabear wrote: I think what you could say is that D lacks _encapsulation_ which is also an OOP concept. So D is partially OOP but not fully OOP due to there being no encapsulation in the language. D does not lack encapsulation, it's just that the unit of encapsulation is the module. Everything private in a module is encapsulated from the perspective of the public API. If you really want to prevent anything inside a module from accessing the private parts of a class, you can put the class in its own module. Must we continue beating this horse? Why is the unit of encapsulation the module though? Makes no sense. It does make sense. But not if the language also provides user-defined types. That is explained in the Stroustup paper I cited. That is, a language that provides modules as well as user-defined types, should provided encapsulation for both. D does that, but for user-defined types it doesn't in the context of other code in the same module as that type. That is why in D you are 'forced' to put that type in its own module 'just' to encapsulate it from other code that would have otherwise been in the same module. No. It makes no sense. A user-defined type should be able to protect hidden data from other code within the same module. That really doesn't sound that extreme to me ;-)
Re: Non-ugly ways to implement a 'static' class or namespace?
On Wednesday, 15 February 2023 at 08:57:27 UTC, Mike Parker wrote: I meant to say, it "wouldn't add more". What if two classes in the module that are several meters apart make `mistakes` that change the privite variable of `another class`? No one can guarantee that after `a few months`, even if you are the author, you will not make mistakes, so as to misuse private variable, while `class level` private can be completely avoided it! There is no maintainability, because two `out-of-class` functions may quietly change your private `variables`.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Wednesday, 15 February 2023 at 08:57:27 UTC, Mike Parker wrote: On Wednesday, 15 February 2023 at 08:56:00 UTC, Mike Parker wrote: If private were restricted to the class/struct, it would add anything more for encapsulation in D. I meant to say, it "wouldn't add more". Well, to quote Stroustrup (from that paper I cited): "A language is said to support a style of programming if it provides facilities that makes it convenient (reasonably easy, safe, and efficient) to use that style. A language does not support a technique if it takes exceptional effort or skill to write such programs; it merely enables the technique to be used." If the only way to protect hidden data within a user-defined type (lets call it a class.. or whatever you want) from other code within the module is to put that type in it's own module, I would argue that D 'enables' data hiding, but does not 'support' it. Of course, I am referring to the context of a module, and any code within that module. The benefit of having the ability to 'not have to' put a user-defined type in a module by itself, simply to enforce data hiding (from other code in a module), seems pretty obvious to me. For example, you could put tightly coupled classes in the same module, and each class would not be able to access the hidden parts of each other (except through an explicit declaration). You'd be able to put unit-tests in the same module, and not have those unit-tests accessing hidden data of your type. Etc...etc. So the benefit is clear. The downside? I (as yet) have never heard a convincing argument for why D should never provide such an option to the programmer, but should instead, continue to force programmers in to the 1-type-per-module design (which is an entirely unreasonable contraint for a language to enforce on a programmer). btw. This is not about beating a horse. I think the point was raised in some comment, and various people (the usual ones, including yourself) have decided to weigh in. That is what results in the converstaion being had ;-)
Re: Non-ugly ways to implement a 'static' class or namespace?
On Wednesday, 15 February 2023 at 08:56:00 UTC, Mike Parker wrote: If private were restricted to the class/struct, it would add anything more for encapsulation in D. I meant to say, it "wouldn't add more".
Re: Non-ugly ways to implement a 'static' class or namespace?
On Wednesday, 15 February 2023 at 07:23:39 UTC, thebluepandabear
wrote:
Why is the unit of encapsulation the module though? Makes no
sense.
What is the purpose of encapsulation? To keep the implementation
details hidden behind the public API, such that changing the
implementation doesn't change the API.
Consider this:
```d
module gfx;
struct Point {
private int x, y;
this(int x, int y)
{
this.x = x;
this.y = y;
}
void move(Point to) {
x = to.x;
y = to.y;
}
}
```
Here, `move` is part of the public API. `x` and `y` are part of
the implementation. Nothing outside the module can touch them.
Now this:
```d
module gfx;
struct Point {
private int x, y;
this(int x, int y)
{
this.x = x;
this.y = y;
}
}
void move(ref Point from, Point to) {
from.x = to.x;
from.y = to.y;
}
```
From the perspective of the public API, nothing has changed. The
following works in both cases:
```d
Point p;
p.move(Point(10, 20));
writeln(p);
```
In both cases, the implementation is hidden behind the same
public API.
If private were restricted to the class/struct, it would add
anything more for encapsulation in D. In practical terms, if you
are editing the `gfx` module, you also have access to the
implementation details of `Point`.
Sure, if you have e.g., a special setter that does some extra
work when a member variable is set, you want to ensure that only
that setter is used to change the member variable. But that's
true *inside the class/struct* as well.
I mean, just consider this:
```d
class C {
private enum minX = -100;
private int _x;
void setX(int newX) { _x = newX > minX ? newX : minX }
void doSomething(State s) { setX(_x + s.val); }
}
```
vs. this:
```d
class C {
private enum minX = -100;
private int _x;
void setX(int newX) { _x = newX > minX ? newX : minX }
}
void doSomething(C c, State s) { c.setX(c._x + s.val); }
```
Ideologically, they are not the same. In practical terms, they
are. Whether the closing brace of the class declaration is before
or after `doSomething` matters not one bit. Yes, things can go
wonky in a module that's many lines long and someone sets `_x`
from outside of the class. So what? The same is true for a class
that's many lines long when someone adds a new method that
directly sets `_x` rather than going through the setter.
D's modules are intended to be used for grouping related
constructs. Everything in the module is part of the same private
implementation. If the constructs aren't related, then put them
in separate modules. And there's still a solution for anyone with
a strict ideological preference regarding related constructs:
they can put their classes and structs in individual modules
under a common package. `package` protection can be used for
cross-module access inside the package, and the entire set can be
presented to the outside world as a single module with
`package.d`.
Our friend of many forum handles misses no opportunity to return
to this putrid horse corpse to beat it some more, but the meaning
of private isn't going to change. This is D's approach to
encapsulation.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Wednesday, 15 February 2023 at 02:14:30 UTC, Mike Parker wrote: On Wednesday, 15 February 2023 at 01:16:00 UTC, thebluepandabear wrote: I think what you could say is that D lacks _encapsulation_ which is also an OOP concept. So D is partially OOP but not fully OOP due to there being no encapsulation in the language. D does not lack encapsulation, it's just that the unit of encapsulation is the module. Everything private in a module is encapsulated from the perspective of the public API. If you really want to prevent anything inside a module from accessing the private parts of a class, you can put the class in its own module. Must we continue beating this horse? Why is the unit of encapsulation the module though? Makes no sense.
Re: Non-ugly ways to implement a 'static' class or namespace?
Time to move on to OCaml programmers telling us D doesn't have floating point arithmetic because there's no `+.` operator. that's not the same thing though, you've created a great false equivalence! Congrats.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Wednesday, 15 February 2023 at 02:14:30 UTC, Mike Parker wrote: On Wednesday, 15 February 2023 at 01:16:00 UTC, thebluepandabear wrote: I think what you could say is that D lacks _encapsulation_ which is also an OOP concept. So D is partially OOP but not fully OOP due to there being no encapsulation in the language. D does not lack encapsulation, it's just that the unit of encapsulation is the module. Everything private in a module is encapsulated from the perspective of the public API. If you really want to prevent anything inside a module from accessing the private parts of a class, you can put the class in its own module. Must we continue beating this horse? Time to move on to OCaml programmers telling us D doesn't have floating point arithmetic because there's no `+.` operator.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Wednesday, 15 February 2023 at 01:16:00 UTC, thebluepandabear wrote: I think what you could say is that D lacks _encapsulation_ which is also an OOP concept. So D is partially OOP but not fully OOP due to there being no encapsulation in the language. D does not lack encapsulation, it's just that the unit of encapsulation is the module. Everything private in a module is encapsulated from the perspective of the public API. If you really want to prevent anything inside a module from accessing the private parts of a class, you can put the class in its own module. Must we continue beating this horse?
Re: Non-ugly ways to implement a 'static' class or namespace?
On Wednesday, 15 February 2023 at 01:15:09 UTC, thebluepandabear wrote: On Tuesday, 14 February 2023 at 15:34:17 UTC, bachmeier wrote: On Tuesday, 14 February 2023 at 10:16:47 UTC, ProtectAndHide wrote: In any case, there is nothing 'picky' about wanting to be able to explicately 'declare' a member of my class type as being private. That to me, is what a programmer should expect to be able to do in a language that says it supports OOP. What you are saying is that you want an implementation of a particular language that calls itself an OOP language. [There is a lot of controversy about the definition of OOP](https://wiki.c2.com/?NobodyAgreesOnWhatOoIs). I do not think the explicit ability to declare a member of a class private in a particular way has anything to do with it. You are certainly entitled to your opinion, but it doesn't help to say D is not an OOP language because you don't like some of the design decisions. D is still an OOP language, as long as it has classes, inheritance, and polymorphism, though it's certainly not a good one if any class can acccess private members from the module, that's just horrid. I think what you could say is that D lacks _encapsulation_ which is also an OOP concept. So D is partially OOP but not fully OOP due to there being no encapsulation in the language.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Tuesday, 14 February 2023 at 15:34:17 UTC, bachmeier wrote: On Tuesday, 14 February 2023 at 10:16:47 UTC, ProtectAndHide wrote: In any case, there is nothing 'picky' about wanting to be able to explicately 'declare' a member of my class type as being private. That to me, is what a programmer should expect to be able to do in a language that says it supports OOP. What you are saying is that you want an implementation of a particular language that calls itself an OOP language. [There is a lot of controversy about the definition of OOP](https://wiki.c2.com/?NobodyAgreesOnWhatOoIs). I do not think the explicit ability to declare a member of a class private in a particular way has anything to do with it. You are certainly entitled to your opinion, but it doesn't help to say D is not an OOP language because you don't like some of the design decisions. D is still an OOP language, as long as it has classes, inheritance, and polymorphism, though it's certainly not a good one if any class can acccess private members from the module, that's just horrid.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Tuesday, 14 February 2023 at 15:34:17 UTC, bachmeier wrote:
On Tuesday, 14 February 2023 at 10:16:47 UTC, ProtectAndHide
wrote:
In any case, there is nothing 'picky' about wanting to be able
to explicately 'declare' a member of my class type as being
private. That to me, is what a programmer should expect to be
able to do in a language that says it supports OOP.
What you are saying is that you want an implementation of a
particular language that calls itself an OOP language. [There
is a lot of controversy about the definition of
OOP](https://wiki.c2.com/?NobodyAgreesOnWhatOoIs). I do not
think the explicit ability to declare a member of a class
private in a particular way has anything to do with it. You are
certainly entitled to your opinion, but it doesn't help to say
D is not an OOP language because you don't like some of the
design decisions.
It's true that not everybody understands what OOP is.
But I think everyone would agree, that data hiding is at the core.
First, I'm not advocating for OOP, or against it.
It's just a tool that's suitable in some scenarios, and not it
others.
I'm also not a OOP purist.
Now with that out of the way
D claims to support OOP. Put that to the test. Because there is a
difference between programming with modules ('Decide which
modules you want and partition the program so that data is hidden
in modules.') and programming with 'user-defined types' ('Decide
which types you want and provide a full set of operations for
each type').
Data hiding is at the core of using modules.
It's also at the core of using types.
I refer interested people to:
"Most, but not all, modules are better expressed as user defined
types." -
What is 'Object-Oriented Programming'? (1991 revised version)
Bjarne Stroustrup
https://www.stroustrup.com/whatis.pdf
Re: Non-ugly ways to implement a 'static' class or namespace?
On Tuesday, 14 February 2023 at 10:16:47 UTC, ProtectAndHide wrote: In any case, there is nothing 'picky' about wanting to be able to explicately 'declare' a member of my class type as being private. That to me, is what a programmer should expect to be able to do in a language that says it supports OOP. What you are saying is that you want an implementation of a particular language that calls itself an OOP language. [There is a lot of controversy about the definition of OOP](https://wiki.c2.com/?NobodyAgreesOnWhatOoIs). I do not think the explicit ability to declare a member of a class private in a particular way has anything to do with it. You are certainly entitled to your opinion, but it doesn't help to say D is not an OOP language because you don't like some of the design decisions.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Tuesday, 14 February 2023 at 10:16:47 UTC, ProtectAndHide wrote: On Tuesday, 14 February 2023 at 08:15:37 UTC, Kagamin wrote: My point is you know you're just picky. Well.. it seems to me, that your 'point' is to just have a go at me. In any case, there is nothing 'picky' about wanting to be able to explicately 'declare' a member of my class type as being private. That to me, is what a programmer should expect to be able to do in a language that says it supports OOP. Further nonsense towards me will be ignored ;-) fight fight fight fight jk
Re: Non-ugly ways to implement a 'static' class or namespace?
On Tuesday, 14 February 2023 at 08:15:37 UTC, Kagamin wrote: My point is you know you're just picky. Well.. it seems to me, that your 'point' is to just have a go at me. In any case, there is nothing 'picky' about wanting to be able to explicately 'declare' a member of my class type as being private. That to me, is what a programmer should expect to be able to do in a language that says it supports OOP. Further nonsense towards me will be ignored ;-)
Re: Non-ugly ways to implement a 'static' class or namespace?
My point is you know you're just picky.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Monday, 13 February 2023 at 09:14:18 UTC, Kagamin wrote: On Monday, 13 February 2023 at 08:22:06 UTC, ProtectAndHide wrote: Chris Lattner outlines the reasons for removing it in Swift 3.0 here: https://github.com/apple/swift-evolution/blob/main/proposals/0004-remove-pre-post-inc-decrement.md So your complaint is that you agree with Chris Lattner and disagree with others? I was just responding to your comment about '++'. What is your point? That I should not complain about not being able to 'declare' type private? (in a language that says it support OOP). My request is not odd. What is odd, is the complete and utter rejection of it ;-)
Re: Non-ugly ways to implement a 'static' class or namespace?
On Monday, 13 February 2023 at 08:22:06 UTC, ProtectAndHide wrote: Chris Lattner outlines the reasons for removing it in Swift 3.0 here: https://github.com/apple/swift-evolution/blob/main/proposals/0004-remove-pre-post-inc-decrement.md So your complaint is that you agree with Chris Lattner and disagree with others?
Re: Non-ugly ways to implement a 'static' class or namespace?
On Monday, 13 February 2023 at 07:19:49 UTC, Kagamin wrote: On Friday, 10 February 2023 at 21:52:02 UTC, ProtectAndHide wrote: Well in Swift, there is no problem .. at all. Why is it a problem in D then? (and I mean technically). What about the increment operator `++` ? Remember, that a one of the design goals of Swift was to NOT continue the 'continuity with C'. This is a very, very, very different goal to D. Personally, I've never liked ++ and -- (and I have for many years, wrote them out the way Swift now requires.). So for me, Swift does exactly what I want here ;-) Chris Lattner outlines the reasons for removing it in Swift 3.0 here: https://github.com/apple/swift-evolution/blob/main/proposals/0004-remove-pre-post-inc-decrement.md
Re: Non-ugly ways to implement a 'static' class or namespace?
On Friday, 10 February 2023 at 21:52:02 UTC, ProtectAndHide wrote: Well in Swift, there is no problem .. at all. Why is it a problem in D then? (and I mean technically). What about the increment operator `++` ?
Re: Non-ugly ways to implement a 'static' class or namespace?
For a language that claims to supprot OOP, and does public by default, and no way to declare type private... I mean... wow! agree, it should definitely be `private` by default... if `private` was implemented properly lmao
Re: Non-ugly ways to implement a 'static' class or namespace?
On Saturday, 11 February 2023 at 02:17:09 UTC, thebluepandabear wrote: I'm not an advocate of any style in particular. I'm happy to use any style that is clear to understand and use, suitable, and can provide reasonable guarantees around memory safety and correctness. But a language that claims to support OOP but doesn't even have type privacy, is a bit of joke IMO. agreed, the current behaviour of `private` is inexcusable, and it's something newcomers need to be warned about. that wasn't my first 'shock' when I came to D. My first shock, was that 'public' was default! New comers should know that before they even begin their first line in D. For a language that claims to supprot OOP, and does public by default, and no way to declare type private... I mean... wow!
Re: Non-ugly ways to implement a 'static' class or namespace?
On Saturday, 11 February 2023 at 02:18:48 UTC, thebluepandabear
wrote:
What attracts me to D, is the inability to program outside of
a class in C#. I think they are trying to find ways to make
this happen, but I wouldn't hold my breath.
programming outside of a class is overrated though in my
opinion. i've never seen a usecase for it in an object oriented
language. Of course Kotlin can do this, which is good, but you
can just create utility classes (i.e. `static class` in C#,
`final class` in Java with a private ctor, or Kotlin `object`.)
Yes, it's overrated, I agree, especially with C# static classes.
still... in Swift, you can do hello world, just like this:
print("Hello World!");
Of course in C# dotnet 5, you can use top-level statements now:
using System;
Console.WriteLine("Hello World!");
(but that's just syntactic sugar .. the class, main etc. is
actually generated behind the scenes.) I don't use top-level
statements though, as find them completely pointless (and
annoying) in C#.
The shortest syntax in D, for hello workd - as far as I know, is:
import std.stdio;
void main()
{
writeln("Hello World!");
}
Re: Non-ugly ways to implement a 'static' class or namespace?
On Saturday, 11 February 2023 at 02:15:37 UTC, thebluepandabear wrote: That's not entirely correct. I don't use any Apple hardware products. Never have, and never will. I use Swift on Linux only. There are of course some library features of Swift tied to Apple products. But I have no need for those library features. As a standalone language, Swift can (IMO) already out compete D. Swift on Linux? Interesting... what is the use case? .. something to play with when not programming in C#. But its not a 'play' language. It's a seriously well designed language. Swift is also available on Windows.
Re: Non-ugly ways to implement a 'static' class or namespace?
What attracts me to D, is the inability to program outside of a class in C#. I think they are trying to find ways to make this happen, but I wouldn't hold my breath. programming outside of a class is overrated though in my opinion. i've never seen a usecase for it in an object oriented language. Of course Kotlin can do this, which is good, but you can just create utility classes (i.e. `static class` in C#, `final class` in Java with a private ctor, or Kotlin `object`.)
Re: Non-ugly ways to implement a 'static' class or namespace?
That's not entirely correct. I don't use any Apple hardware products. Never have, and never will. I use Swift on Linux only. There are of course some library features of Swift tied to Apple products. But I have no need for those library features. As a standalone language, Swift can (IMO) already out compete D. Swift on Linux? Interesting... what is the use case?
Re: Non-ugly ways to implement a 'static' class or namespace?
I'm not an advocate of any style in particular. I'm happy to use any style that is clear to understand and use, suitable, and can provide reasonable guarantees around memory safety and correctness. But a language that claims to support OOP but doesn't even have type privacy, is a bit of joke IMO. agreed, the current behaviour of `private` is inexcusable, and it's something newcomers need to be warned about.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Friday, 10 February 2023 at 02:57:42 UTC, zjh wrote: On Friday, 10 February 2023 at 02:04:06 UTC, ProtectAndHide wrote: "Before practicing Zen, mountains were mountains and rivers were rivers. While practicing Zen, mountains are no longer mountains and rivers are no longer rivers. After realization, mountains are mountains and rivers are rivers again." Chinese proverb, is it very cool? you'll find this mentioned towards the end of this article: "The Importance of Being Closed" https://martinfowler.com/ieeeSoftware/protectedVariation.pdf
Re: Non-ugly ways to implement a 'static' class or namespace?
On Friday, 10 February 2023 at 23:24:11 UTC, thebluepandabear wrote: I think the 'real' problem, is that some core D people just refuse to allow D to provide such an option to the programmer. I think a lot of it has to do with the fact that heaps of D programmers write procedural code and don't care about any object oriented features, that's because they're 'old-school' programmers, whereas OOP is 'new-school'. OOP is not 'new-school' ..not by any means... It had a period where it became 'more popular', that is for sure. Some took it too far, as this has caused some friction, with many languages deciding to rebel against that style. It is true, that no core D users will advocate anything OOP, that is for sure ;-) However the language claims to support OOP, so there is some tension when newbies come to D and actually try it out. I'm not an advocate of any style in particular. I'm happy to use any style that is clear to understand and use, suitable, and can provide reasonable guarantees around memory safety and correctness. But a language that claims to support OOP but doesn't even have type privacy, is a bit of joke IMO.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Friday, 10 February 2023 at 23:22:34 UTC, thebluepandabear wrote: A good example of a language that does everything right is C#. If C# wasn't tied to Microsoft, it would honestly be pretty much the perfect language. Java is also pretty good, but it has its downsides. I don't agree with all of that. C# is certainly one of 'great' programming languages. Particulary because of its extensive framework library, which D could never compete with. Also, the move to open-source, and the move to cross platform with dotnet, makes C# (dotnet) a very attractive option for many use cases, and will certainly see the language being used more and more... I don't necessarily have a problem (anymore) with it being tied to Microsoft (because of the above). Also, Microsoft can afford to employ 'the best', which is what they indeed do, and which is why C# is what it is today. What attracts me to D, is the inability to program outside of a class in C#. I think they are trying to find ways to make this happen, but I wouldn't hold my breath. If only D 'really did' support OOP, as it claims, it would be more useful to me.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Friday, 10 February 2023 at 23:19:31 UTC, thebluepandabear wrote: I think the 'real' problem, is that some core D people just refuse to allow D to provide such an option to the programmer. For what reason, I cannot fathom, since Swift can do this just fine. I think it's some kind of bias against a particular style of programming that some don't want to see occuring when people use the D programming lanuguage. i.e. It has nothing at all to do with implementation, since it's already been demonstrated that it can be implemented, very easily. Again, in this particular area, Swift is way ahead of D. Sorry, but I do not believe Swift is near to the level of what D is, it's a language that's tied - like jail - to Apple's ecosystem, and its only real use is for iOS apps. They're two completely different languages in general. That's not entirely correct. I don't use any Apple hardware products. Never have, and never will. I use Swift on Linux only. There are of course some library features of Swift tied to Apple products. But I have no need for those library features. As a standalone language, Swift can (IMO) already out compete D.
Re: Non-ugly ways to implement a 'static' class or namespace?
I think the 'real' problem, is that some core D people just refuse to allow D to provide such an option to the programmer. I think a lot of it has to do with the fact that heaps of D programmers write procedural code and don't care about any object oriented features, that's because they're 'old-school' programmers, whereas OOP is 'new-school'.
Re: Non-ugly ways to implement a 'static' class or namespace?
A good example of a language that does everything right is C#. If C# wasn't tied to Microsoft, it would honestly be pretty much the perfect language. Java is also pretty good, but it has its downsides.
Re: Non-ugly ways to implement a 'static' class or namespace?
I think the 'real' problem, is that some core D people just refuse to allow D to provide such an option to the programmer. For what reason, I cannot fathom, since Swift can do this just fine. I think it's some kind of bias against a particular style of programming that some don't want to see occuring when people use the D programming lanuguage. i.e. It has nothing at all to do with implementation, since it's already been demonstrated that it can be implemented, very easily. Again, in this particular area, Swift is way ahead of D. Sorry, but I do not believe Swift is near to the level of what D is, it's a language that's tied - like jail - to Apple's ecosystem, and its only real use is for iOS apps. They're two completely different languages in general.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Friday, 10 February 2023 at 14:50:59 UTC, bachmeier wrote: On Friday, 10 February 2023 at 07:04:31 UTC, Max Samukha wrote: Having class-private doesn't preclude module-private. Dennis even submitted a PR implementing class-private, but it stalled because people couldn't agree on whether class-private should be "private to class" or "private to class instance". This is a great example of the problem. In a discussion of any five programmers, you'll have five conflicting sets of rules that are the obvious and intuitive way to do it. Well in Swift, there is no problem .. at all. Why is it a problem in D then? (and I mean technically). I think the 'real' problem, is that some core D people just refuse to allow D to provide such an option to the programmer. For what reason, I cannot fathom, since Swift can do this just fine. I think it's some kind of bias against a particular style of programming that some don't want to see occuring when people use the D programming lanuguage. i.e. It has nothing at all to do with implementation, since it's already been demonstrated that it can be implemented, very easily. Again, in this particular area, Swift is way ahead of D.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Friday, 10 February 2023 at 07:04:31 UTC, Max Samukha wrote: Having class-private doesn't preclude module-private. Dennis even submitted a PR implementing class-private, but it stalled because people couldn't agree on whether class-private should be "private to class" or "private to class instance". This is a great example of the problem. In a discussion of any five programmers, you'll have five conflicting sets of rules that are the obvious and intuitive way to do it.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Friday, 10 February 2023 at 14:17:25 UTC, Kagamin wrote: Pretty sure you can strip namespaces in any language that has namespaces, C# routinely does it and refers to all types with their nonqualified names. It even has Keys enum: https://learn.microsoft.com/en-us/dotnet/api/system.windows.forms.keys which is referred to as Keys after stripping the System.Windows.Forms namespace. An example from KeePass: https://github.com/dlech/KeePass2.x/blob/VS2022/KeePass/Util/SendInputExt/SiCodes.cs#L86
Re: Non-ugly ways to implement a 'static' class or namespace?
On Monday, 23 January 2023 at 00:36:36 UTC, thebluepandabear wrote: It's not a freedom issue, it's a library-design issue. Some libraries want to incorporate a namespace-like design to force the user to be more 'explicit' with what they want. SFML has a `Keyboard` namespace which has a `Key` enum. The user is 'forced' (although I am not sure if this is the case since it's C++) to use the `Keyboard.` declaration before using the `Key` enum. Looking at code block 1 and 2, which makes more sense? Pretty sure you can strip namespaces in any language that has namespaces, C# routinely does it and refers to all types with their nonqualified names. It even has Keys enum: https://learn.microsoft.com/en-us/dotnet/api/system.windows.forms.keys which is referred to as Keys after stripping the System.Windows.Forms namespace.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Thursday, 9 February 2023 at 20:05:06 UTC, Ali Çehreli wrote: Besides, D has zero problems with its private implementation in the sense that there has been zero bugs related to it being that way. That is how a Python aficionado would defend the absence of visibility attributes therein. "We don't have them, because _ is enough, and there are no bugs". And I would agree that D would be better off without visibility attributes entirely instead of having unending issues with them (private aliases, private + reflection, private + synchronized/invariant, etc). In contrast, I use D every day and love its relaxed attitude towards private. Having class-private doesn't preclude module-private. Dennis even submitted a PR implementing class-private, but it stalled because people couldn't agree on whether class-private should be "private to class" or "private to class instance".
Re: Non-ugly ways to implement a 'static' class or namespace?
On Friday, 10 February 2023 at 02:04:06 UTC, ProtectAndHide wrote: "Before practicing Zen, mountains were mountains and rivers were rivers. While practicing Zen, mountains are no longer mountains and rivers are no longer rivers. After realization, mountains are mountains and rivers are rivers again." Chinese proverb, is it very cool?
