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=beta=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: ELIZA Chatbot Implementation From C to D Lang
On Friday, 17 February 2023 at 17:03:34 UTC, ron77 wrote: Hello, I succeeded in converting an ELIZA code from C to D, and here are the results. although I'm sure there are better ways to code it or to convert it... this is nothing compared to chatgpt ;)
Re: ELIZA Chatbot Implementation From C to D Lang
On Friday, 17 February 2023 at 17:03:34 UTC, ron77 wrote: Hello, I succeeded in converting an ELIZA code from C to D, and here are the results. although I'm sure there are better ways to code it or to convert it... [...] Among the things to do the first is to drop C-style strings, so that you can get rid of `strlen()` and `strcat()` for example. Then maybe try to rewrite your for-loops as UFCS pipes. Have fun.
